When you've got a pile of bugs and features, it's usefull to separate severity from priority in order to prioritize them. 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.
- Critical feature broken - customer cannot perform a significant expected function. This defect is causing system failure. It may also be called "show stopper."
- Major feature broken - but there are work arounds
- Medium - is causing some undesirable behavior, however system / feature is still usable to a high degree (there is a work around).
- 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
- Urgent: requires hotfix to production
- High: must be fixed this sprint (within two weeks)
- Medium: should take precedence over low priority defects and may be fixed after the release / in the next release.
- 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.