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

One option is to have the product owner determine the priority of the bug. While there is some general intuition on how "bad" a bug is, it can be the responsibility of the owner of the product to set an order of precidence (i.e. bug A should be fixed before bug B etc...).

The more information (clear and concise) that can be provided to the product owner can assist that individual make those determinations (i.e. how many users have experienced the bug, what features are not available as a result of the bug, etc...)

Answer 2

"Been there done that".

I've had this discussion over and over again, on different projects. We've tried to combine priority with severity, but the lesson I've learned: do not combine severity with priority !

We've had a lot of brainstorms and meetings which ended with the words "this is it". Multiple guideline-documents have been created and spread between the different "parties", but after a while we discovered that it didn't work at the end. Different "parties" think different about bugs: our helpdesk has another understanding of priority than the development team or the sales has.

Having both a severity and a priority level will very quickly become very confusion because:

• when using numbers (between 1 to 5) one will not know what each number means
• what if an issue has the highest possible priority, but the lowest possible severity - and I'm sure that this will happen!
• what if someone reduces a severity, does he need to reduce the priority also?

"So what should you do then?":

• Only use one kind of indicator for the 'level' of an issue: Doesn't matter how you call it.

• Use numbers (eg 1 - 5, but could be more or less depending on your needs) to clearly indicate the importance but combine it with a keyword so that it's clear what it means (eg. 'nice to have', 'show stopper'). For some people prio 1 means the most import, for others 5 does -> therefore a keyword to indicate what a number means is necessary.

• Make a distinction between a 'normal issue' or a 'red alert'. In our case a 'Red Alert' must be solved immediately and put in production immediately. A normal issue will follow the normal development-test-deployment-flow. The priority/severity/however-how-you-call-it should only be set for normal issues and will be ignored for 'red alerts'. *> In practice, a 'Red Alert' can become a

  'Normal Issue': the support team discovered a major bug and created a 'Red Alert'. But after some investigation we discovered that data had become 'corrupt' in the database since it was inserted there directly and not via the application.*

• Choose a good tool that allows you to customize the flow; but most tools do.

Answer 3

I use the following categories both for features and bugs:

1. Showstopper, the program (or a major feature) will not work
2. Must have, a significant part of the customers will be bothered by this
3. Would have, some customers will be bothered
4. Nice to have, a few customers want this

Normally you plan to fix 1, 2 and 3, but 3 is often postponed to a next release due to time constraints.

Answer 4

Set the requirements of the project so you can base the priority of a fix on the priority of the requirements interfered by the bug.

Answer 5

I think this is the scale we used at a previous job:

1. Causes loss of files or system instability.
2. Crashes the program.
3. Feature doesn't work.
4. Feature doesn't work, but there are workarounds.
5. Cosmetic issue.
6. Request for enhancement.

Sometimes this was abused - if a feature was so poorly designed that someone couldn't figure out how to use it, that was classified as a 6, and it never got fixed.

Answer 6

As for a standard, IEEE guide to classification for software anomalies although I am not sure how widely this is adopted. IEEE 1044.1-1995