Bug Management: High priority to released defects.
In a previous post, I was proposing to automatically assign a very high priority to a defect reported by a user (user in the released product). Arguably many of these defects are not critical and for the critical ones arguments against this idea will be short lived.
Why assign a high priority to non critical defects reported by a user ? I have at least two good reasons for this.
First, because a user took the time to report such a defect, it had to be very visible and quiet annoying at the time he discovered it. That should be enough to put it ahead of anything that was found in the rest of the software development process that was not scheduled immediately for a fix.
Second, it is a very strong signal from the team to the user that his feedback is valued and acted upon. This in turn will encourage users to report not only cosmetic defects but also inefficiencies in the way their workflow is implemented. It is actually something that I have noticed in many cases, until the cosmetic noise is gone, many users do not focus on the actual workflow and usability.
In many cases, our appreciation of what is important is different from our users’. Putting a high priority on defects that are reported by the user makes sure we do not substitute our priorities to his.
What do you think ? Are defect reports from your users useful ? Is it easy for them to report defects ? Would this introduce too much noise in the defect tracking system ?
February 11th, 2009 at 7:20 pm
“No broken windows” is just as powerful on the users as on the developers. It demonstrates that you care about the user’s experience, that you listen, and that you act on their feedback. I totally agree with your proposal with one clarification you might have intended but didn’t state explicitly: Do remind users that the feedback you just captured will all go in as “high” so they can choose to lower that.
I do have a couple of related questions:
- What’s your current mechanism for reporting to users what just got released?
- What’s your expected cycle time on these high items?
César.
February 14th, 2009 at 1:28 am
Release notes although lately I made a point of sending an email with the link to the artifact generated by their feedback. This is not satisfying. RSS feeds or automated emails would be better.
As for expected cycle time as we discussed off line it really depends on your users. I think in the financial sector a cycle of a month is acceptable. A daily or a weekly patch (which is what Bloomberg does) would be ideal. And with a good development process it is very manageable.