Please note that this post was migrated to my new blog platform. There may be bad formating, broken links, images, downloads and so on. If you need an item on this page, please contact me and I will do my best to get it from my backups.

All too often, I get involved with ticketing systems that have these set incorrectly.  Or, they utilize them in a different manner than what they were intended for.  Tonight, I am setting up another system and thought I would document the differences here for future references (and for my buddies that could tweak their systems).

I understand there is a movement to get away from setting both of these.  I myself like a system without the severity part, as it is much faster just to run down the priority list.  But, I feel that the more formal the QA process is (e.g. you have a dedicated QA member or team or outsourced group), the more you need to separate the two.  This post should help with that.

Definitions of Severity and Priority

The definitions, in terms of a ticketing system are as follows:

Severity : The level of impact the defect has on the system, overall.  Basically, how serious the bug is. 

Priority : The developers order in which to attack, address, or fix the tickets.  Ranked usually from Highest to Lowest.

Before going any further, let’s setup the Severity to match what Microsoft uses (sourced from this article, with my spin on it). 

1 - Exception or Crash : A system crash or anything that loses persistent data.  Often times referred to as Show Stoppers.  Most of the time your overall exceptions that users see (or get the generic “and error has occurred” page) would fall into this category.  Unless related to a new feature being QA’d (see #2 below).

2 - New Feature Incomplete : A new feature that does not work at all or has exceptions.  The word new being import there, as broken new feature bugs do not belong in #1 above.

3 - Release Feature Bug : A completed feature that can be released, but has some rough edges to iron out further.

4 - Cosmetic (UI) : Purely cosmetic, css, html, and spelling issues.

I usually take it a little further by adding a 5th option.

5 - Feature Request : Usually a placeholder for feature notes and feature development / feedback to the reporter.  Some organizations prefer to keep a separate list of these.  I find they are too often forgotten about.

It is easier to think of severities as categories of the defect itself.  Also if you notice, I prefixed the severities with numbers.  This has a two effects by giving users an instant “what level is this bug” resolve, as well as a trick to get several ticket systems to order the DropDownList by the number (yeah, lame, but works!).

Who sets Severity and Priority?

This is a good one.  A few employees at my last company nearly went to war over who gets to set these.  But, the answer is simple:

It’s the tester/bug reporter’s job to set the severity.

The person in charge of QAing the system knows the severity of the bug they are reporting.  They know how it impacts the users on the other end.  But, this person should not be given the power to set the priority.  Else, everything would be set to High Priority (usually the case).

Priority should be set by the project manager or dispatcher.

During the weekly standup, the project manager decides on what order the tickets are addressed in and this, in turn, dictates the priority of the tickets.  This is done by examining the severity of the bug reported (yep, there it is - examine the severity here!).  After reviewing the severity, the PM estimates the time to resolve the bug for the next milestone or release and decides if it is acceptable.  If so, a priority is set on the ticket and it is moved to the appropriate milestone.

Severity and Priority Examples

Let’s take an example of an css issue in which the overflow property is not set correctly, and the text the user sees is being obscured by this issue.  But, this css issue is part of a new feature that is going out in the next build.  What do you set it to?  Is it #2, a feature incomplete?  Or #3, a feature bug because the user cannot set the text of this “new” feature?  Or, #4, an UI issue?

Personally, this is to each his own.  I would examine the context of the text being hidden.  If this text is the balance of your bank account being hidden, then that is a #2.  If it is part of the help text, then #3 and can be released to be tweaked later.  If it is just a few words not needed for any operation or description of the page’s purpose, then, it’s #4 and can wait for more sever issues to be addressed.

Basically, the severity dictates rather that bug must be completed before release.  I usually set the rule that the release does not go out with any #1 and #2s in the list.  Or, I may release some #2s if I can quickly follow-up with a patch within a day or two. 

Number 3s and 4s often time get pushed back until the next release, unless the priority has been bumped (i.e. how old a ticket is).  The #3s and #4s are great gap fillers for those “let’s run through the tickets and attack as many as we can” days.

If you need more examples, feel free to hit me up or leave a comment.

Summary

Hopefully you have a better idea of severity and how it fits into your project management.  Again, I have to stress that smaller projects may never use severity.  But, if you have any type of format QA process, it makes sense to stick it in there to have the extra level of communications.

In case you are wondering, I personally use Unfuddle at my companies and personal projects.  You can’t beat the web version of diffmerge in the browser!  GitHub is very good as well for those diffmerges.  GitHub is best suited for public projects and very small teams, and is only for Git.  Where Unfuddle supports both Git and SVN, and is more privatized.