How to prioritize bugs?

Question

In my current company there isn\'t clear understanding between the test and development teams as to how severe a bug should be? There are arguments which go back and forth to re

Answer 1

• Use priority levels that deliberately have nothing to do with severity or impact, and describe only the conceptual position of the bug in the schedule. This field will determine which bugs get worked on, so it needs to be very clear that the facts of the bug aren't open for negotiation.

• Use severity levels that deliberately have concrete, verifiable definitions, that have nothing to do with scheduling or priority. I've worked successfully with the severity definitions used by the Debian BTS, generalised to apply to programming projects in general.

That way, the severity is much more a matter of verifiable fact, independent of a statement of priority. The priority is then free to be tweaked up and down by negotiation or whatever, without affecting the factual information in the severity field.

Attempting to conflate both “severity” and “priority” into a single field will lead to soul-draining arguments and wasted time. The bug reporter needs a firm guide of fact to determine how “bad” the bug is, and this needs to be easily agreed on by independent parties. The priority, on the other hand, is the correct target for negotiation and scheduling games.

Answer 2

I work on emergency control centre systems, so this set of bug levels is a little, well... extreme:

• someone dies
• total system failure requiring DR invocation
• server failure requiring engineer response
• failure involving loss of call continuity
• failure involving loss of data
• incorrect data recorded
• application failure - non-recoverable
• application failure - non-recoverable, but automatically restarted
• does not meet requirement spec, no workaround
• does not meet requirement spec, but has workaround
• cosmetic - layout etc.
• actually a feature request

That's off the top of my head. In case you were wondering, it's from most extreme to least :-)

Answer 3

Replace your bug tracking system with fogbugz and get rid of severity field altogether.

See Priority vs Severity

Answer 4

I agree with the FogBugz folks that this should be kept super simple: http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

I made up this scheme, which I find easy to remember:

• pS: seconds matter, eg, server is on fire
• pM: minutes matter, eg, something is broken
• pH: hours matter, ie, don't go to bed till this is done
• pd: days matter, ie, normal priority
• pw: weeks matter, ie, lower priority
• pm: months matter, ie, no hurry
• py: years matter, ie, maybe/someday, ie, wishlist

It roughly parallels Debian's scheme: http://www.debian.org/Bugs/Developer#severities

I like it because it straightforwardly combines priority and severity into a single field that's easy to set a value for.

PS: You can also pick intermediate urgencies like "pMH" for in between "minutes matter" and "hours matter". Or "pHd" is in between "hours mattter" and "days matter" -- roughly, "don't literally pull an all-nighter for it but don't work on anything else till it's done".

Answer 5

• The tester tells what is broken
• The developer estimates how much work it will be to fix
• The customer decides the business value, i.e. the priority.

Answer 6

Some stuff we used before. We split the defect rating into priority and severity.

Severity (set by submitter during submission of defect)

• Highest (5): Data loss, hardware damage possible, or a security-related failure
• High (4): Loss of functionality without any reasonable workaround
• Medium (3): Loss of functionality with a reasonable workaround
• Low (2): Partial loss of a function or a feature set (feature still hits the design requirements)
• Lowest (1): A cosmetic error

Priority (adjusted by development, management and QA during defect evaluation)

• Highest (5): The system is practically unusable with this defect.
• High (4): The defect will have a serious impact on the company’s ability to sell and maintain this system.
• Medium (3): The company will lose some money if this defect is in the system, but it might be more important to meet the schedule. Fix after release.
• Low (2): Do not delay the release, but do fix this problem afterwards.
• Lowest (1): Fix as time and resources allow.

Both numbers together create a risk priority number (RPN). Simply multiply severity with priority. Higher result means higher risk. 25 defines the ultimate defect bomb. 1 can be done during idle time or if someone is bored and needs something to do.

First goal: Defects with a rating of highest or high of any kind should be fixed before release. Second goal: Defects with RPN > 8 should be fixed before releasing the product.

---

This is of course a little bit artificial but helps to give all parties (Support, QA/Test, Engineering, and Product Managers) a tool to set priorities without blowing away the opinion of other side.