John Luif

As a consultant I find I tend to take the little things for granted.  I happen to know if a small company that is filled with very smart people having backgrounds from many different places.  The challenge they faced was how to manage defects.  The discussion revolved around having both Severity and Priority and it resulting in to many possible combinations.

I always recommend using both Severity and Priority no matter what the size of the organization is.  This is contrary to some other beliefs out there on having both Severity and Priority but the overhead of having both is minimal and return is high.  They provide two completely different pieces of information that are usually supplied by different people.

Severity is how bad is the problem.  This is usually (and should be) supplied by the person who found the bug.  Very rarely is severity changed from the original value set by the person who logged the bug.

Priority gives a level of importance which results in time frame of completion.  Priority is usually assigned at a bug triage meeting and is decided upon by more than one person.

By using both Severity and Priority you can get a good idea of what has to be completed and when.  Depending on when certain pieces of code go live you may have a low severity bug as a very high priority because even though simple needs to be completed before the code is released.  Severity is definitely not a good indication of when bugs should be done.