Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 516 posts at DZone. You can read more from them at their website. View Full User Profile

Bugs: Prioritising by Bucket

12.22.2010
| 4407 views |
  • submit to reddit

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/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(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

Great, I was planning to write the same thing. We have bugs planned for milestones plus specific deadline for some bugs and the estimated solution time. Thus you can manage the order yourself very well by paying attention to the deadlines and time it takes to do tasks.

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

For business applications that I develop, the business actually decides what gets prioritized to be fixed on the next release, often overriding the QAs.

Andy Leung replied on Wed, 2010/12/22 - 11:43pm in response to: Aries McRae

Definitely!!! Because developers write software for business! But I would say whoever runs UAT testing should work with Business Analyst and Project Manager to rank the priority; neither developers or QA should prioritize defects unless that defect is obvious defect impacting system stabilities, performance or security. Often because business could change their minds to remove the defect related requirement out-of-scope to allow project implementation as they see that functional requirement may not be worth the time to fix at this moment.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.