What’s the difference between “Priority” and “Severity?”

What’s the difference between “Priority” and “Severity?”

       Every case in the system is given a priority from 1 to 7, where 1 is the highest priority. The default for new cases is 3.

1. Life or death emergency… the roof is actually on fire. Drop everything and fix.
2. A customer is waiting for this
3. Very important
4. Important
5. Not so important – fix if time
6. Probably won’t fix but worth remembering
7. Do not fix

The best way to use priorities is to have a single, global priority scheme across all your projects, bugs, and features, so that every team member can always work down their list of cases in order of priority.

Many older bug tracking systems had two fields, priority and severity.

Priority represents the importance of fixing a bug, and reflects a business decision as to how soon that bug should be fixed: all priority 1 bugs should be fixed before priority 2 bugs, etc.

Severity represents “how bad a bug is.” For example, a bug that causes the program to crash would be considered high severity, while a small spelling error might be low severity.

But wait a minute … if that spelling error is in a frequently-used part of the program, it might give an overall bad impression that hurts the product’s sales. And if the crashing bug happens extremely rarely and only under very unusual circumstances, you may decide that the spelling error is actually more important. So you could imagine having a high severity bug with a low priority, or vice versa.

You need to decide which bugs are going to get done first, and you need to be able to search for high priority bugs or sort bugs by priority. But if a bug is a low priority, the additional piece of information that it is “high severity” is merely confusing, since you’re still not going to fix it until all the higher priority bugs are done.

If we required bug submitters to decide both the severity and the priority of a bug, that would increase the amount of thought and work it takes to enter and manage that bug. Each time you enter a bug, you would have to make two hard decisions, only one of which really matters in the long run. Most of the time, the priority and severity are the same; when they’re not, the severity is not worth keeping track of.

The most important factor in successful bug tracking is getting every bug captured in the system. We’ve found that in the real world, anything which increases the mental friction of inputting a bug will dramatically reduce the number of bugs entered.