Bugs: Prioritising by Bucket
At a lot of organisations that I've worked there is a tendency to prioritise bugs by a priority bucket.
We might therefore have priority buckets 1-4 where the bucket number indicates how important the bug is to fix and then any buckets ranked below 4 would not be fixed but would be logged anyway.
From what I've noticed this isn't a particularly effective way of managing bugs.
To start with there tend to be a lot of discussions around what the priority of each bug should be where a QA will argue that it should be a higher priority while a developer disagrees.
I'm not convinced that we actually get any value out of these discussions.
Another thing that I've noticed recently is that developers are much less motivated to fix bugs if they've been put in Bucket 4 rather than one of the higher priority buckets.
I think a better way to solve this problem is just to store whether or not we're going to fix the bug before the next release or not. We can then list them in the order that they should be fixed as well.
It's a much simpler binary categorisation and there's no stigma attached to picking up a 'low priority' bug because each bug picked up is just the next one on the list.
We did this on one project I worked on and it was interesting to notice the number of bugs the client was completely disinterested in fixing before the next release because they just weren't that important.
I'm not convinced the same thing would have happened if we'd categorised by bucket.
The added benefit of this approach is that we can avoid discussions where we identify how many bugs of each category have been identified each iteration.
In some organisations the ability to detect higher priority bugs is an indication of the quality of QA work but I don't believe this is a useful metric to track.
From http://www.markhneedham.com/blog/2010/12/12/bugs-prioritising-by-bucket/
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Jevgeni Kabanov replied on Wed, 2010/12/22 - 7:35am
Developer Dude replied on Wed, 2010/12/22 - 1:19pm
My current client uses Test Track and during triage we can specify 'priority', impact (how bad is the bug) and which release the bug will get fixed in. I do think it would be better to have a scale of zero to ten (with ten being the highest priority).
As for fixing higher priority bugs v. low priority - yes, I tend towards fixing higher priority bugs first, but I also tend towards fixing bugs that are in a particular functional area, or that may be related, or that are in a given area of code - i.e., if I am in there to fix one bug I might as well fix the other bugs (regardless of priority) while I am messing with the code and testing it, rather than jumping back and forth based solely on priority. This way I don't have to change gears so often with regards to understanding what is happening in the code and with testing. Also, a not insignificant number of bugs are either duplicates (to a certain degree) or related to other bugs - so fixing them together is usually more efficient and results in better code.
Finally, I like to mix it up a little. I don't want to be tackling one hard bug after another. Sometimes difficulty has nothing to do with priority, sometimes it does, but I like to fix a few hard bugs and then fix some easy ones to give my brain a rest. At first I do tackle the riskier/harder/higher priority bugs first if there is any question about a deadline not being met, or if it is blocking someone/something - but I don't want someone specifying what strict order I fix bugs in (this bug, then that bug). As long as I get my work done in a reasonable amount of time and I take into account the priorities and impacts on other people, *I* usually decide which bugs to fix when and I have had no complaints to that end.
So, during triage we can assign priorities all we want, and I will just fix bugs as my work style/load permits. I usually listen to the PMs/QA/SMEs on priority because they are usually closer to the user/domain than I am and they usually know what is important to the user better than I do. I do occasionally get the PM/QA/SME that thinks most of the trivial cosmetic issues are high priority and the functional failures/crashes are low priorities, but generally the rest of the triage group overrules them.
Aries McRae replied on Wed, 2010/12/22 - 9:15pm
Andy Leung replied on Wed, 2010/12/22 - 11:43pm
in response to:
Aries McRae