Incident Priority vs. Severity - Best Practices

August 22nd, 2014 by inflectra

Our project management system - Spira, contains several standard features for bug-tracking, two of which often get confused, and are often asked about in training classes.  These two are Priority and Severity. They are touched on in the manual, but here it is from the point of a tester.

Incident Severity

Severity is based upon how much of the application is affected. Are all pages broken, is it important? This is an assessment of the issues extent without dealing with where exactly it happens. Also this is a discussion of how severe the problem is without regard to where it falls on the ToDo list.

Severity 1 = Showstopper, major failure that affects the entire system or multiple modules of the system.

  • Hardware failure
  • Network failure
  • Database failure
  • Software failure
  • Cannot log in, no passwords accepted,
  • e-commerce functionality does not work at all

Severity 2 = This is big, a major piece of functionality of the application is broken

  • A major functionality is broken or misbehaving
  • Pages are gone, missing, not displaying at all
  • Important links or buttons are missing
  • Major graphical elements are not displaying

Severity 3 = The feature is not working correctly, but it will not impact users greatly

  • Database issues, no commits, math wrong, file errors (which might not be displayed), no saves
  • Looks different on different platforms (browser, windows version, linux version)
  • Too slow to use
  • Layout issues
  • Broken links on buried pages
  • UI issues, can’t tell what to do

Severity 4 = Could live with the issue, should be fixed when possible

  • Display problems, not lining up, tab order incorrect
  • UI issues, relay bad color choice, works different on each page
  • Content problems, misspellings, font variance, wrong text
  • Page layout issues, like alignment or text spacing

Severity is usually set by the tester when the defect is found.

Incident Priority

Priority is a general assessment of the problem and where it should be inserted in the to-do list for the team. Priority addresses the when. When should we fix this? Should it be handled early in the cycle or late?

  • Priority 1 = This needs to be fixed ASAP. If it isn't fixed, then nothing else matters. This problem affects every part of the application and nothing is higher on the to-do.

  • Priority 2 = Has to be fixed before the next release. It is a big problem and needs to be addressed so that we can move on to other things that are being affected by this. It is very visible and will make us look bad.

  • Priority 3 = Once all the 1 and 2 priority issues are dealt with, get this done. If it doesn't make it, it won’t kill us, but it is still an issue. Could be a part of a specific sprint to do "clean up".

  • Priority 4 = Well, if you have nothing else to do, get this. it doesn't really show up but it has been bugging us for a while.

Priority is often set as a part of defect triage. Determining how severe it is may also be a part of development, or business, triage.

Of course, this example is based on a 4 point scale*, if you have more levels, just redistribute them. The big thing here is that the whole team has a common understanding of how and why certain priority and severity assignments are made, and that they all adhere to that understanding. If the team is cohesive on how these are used it will make the process flow smoother.

*SpiraTeam comes with a 4-point scale for both priority and severity deliberately. If you use a five point scale (or any odd number), you will find during triage that everyone will want to assign all the incidents to priority / severity 3 (right in the middle) and you won't have a good way of understanding which ones are the more important. By forcing a priority / severity 2 vs. 3 the triage forces the 'hard' decision early.

bug tracking priority severity triage