Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
This gist defines "severity" and "priority" as they relate to prioritizing bugs to be fixed.

Separating severity from priority is useful in prioritizing bugs. At the end of the day, priority is all that matters - but severity helps clarify how "bad" the bug is.

Basically, it comes down to...

  • SnP1 = hotfix (where n is any number)
  • SnP2 = in this sprint
  • SnP3 = later (maybe never)

... but almost always, high severity bugs will have a high priority.


Defect Severity signifies degree of impact the defect has on the development or operation of a component application being tested. It is the extent to which the defect can affect the software.

  1. Critical feature broken - customer cannot perform a significant expected function. This defect is causing system failure. It may also be called "show stopper."
  2. Major feature broken - but there are work arounds
  3. Medium - is causing some undesirable behavior, however system / feature is still usable to a high degree (there is a work around).
  4. Low - is more of a cosmetic issue. No serious impedance to system functionality is noted


Defect priority signifies the level of urgency of fixing the bug. In other words Priority means how fast/ how soon it has to be fixed. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.

Defect Priority may range from Low to Urgent

  1. Urgent: requires hotfix to production
  2. High: must be fixed this sprint (within two weeks)
  3. Medium: should take precedence over low priority defects and may be fixed after the release / in the next release.
  4. Low: Fixing can be deferred until all other priority defects are fixed. It may or may not be fixed at all.

When prioritizing bugs, we first sort by priority, then severity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment