I was wondering what other folks out there are using to define and put bonudaries to the different severities and priorities that can be defined in most trackers. For example, what needs to occur for a bug to be considered critical, high, medium, low, etc. Priority high, medium, low etc.
I have some bounds on this now but I want to eliminate as much of the "judngement call" aspect of assigning these as possible. Thoughts?
Severity defined by me is dependent on the manifestation of the defect. The question here to ask is - Does it impede in the achievement of a user objective ?
So, if I come across a memory access violation when I click File|Open - that goes at the very top as ShowStopper severity.
Priority for me is the *visibility* of the bug vis-a-vis the customer/enduser's viewpoint. If there is a spelling mistake on the installation welcome splash screen, thats priority Highest for me.
Usually bugs fall in the Severity "Major with workaround" and Priority "Medium".
Here are my severity types:
ShowStoppper - means Death Doom Destruction Despair!
Major without workaround - functionality problem that does not allow me to accomplish some user objective.
Major with workaround - alternative approach to achieve objective present.
Minor without workaround - can live with the problem, but no alternative.
Minor with workaround - can live with problem, there is an alternative.
Suggestion - Nice to have.
Immediate - I will hover over your head like a vulture until you solve this ! ;-)
High - very next build
Medium - solve before next build if possible
Low - solve if nothing else is around.
Lowest - solving this improves the "image" of the product
'Who really cares which 'severity pidgeonhole' a defect fits into? This only leads to headaches, arguments and things not really fitting in. My defects are rated according to two rules:
1) What order should we attempt to fix them in?
2) When do they need to be resolved by?
For this all you need is a priority rating. We have 6:
A1 - Everybody jump! fix NOW!!
B1 - Fix Next/First
C1 - MUST be fixed before next release
C2 - SHOULD be fixed before next release (but we'll survive if time constraints don't allow)
C3 - NICE to fix but we don't expect to have time.
D4 - Ok, it's a bug but it's not in anyone's interest to spend any more time on it.
Of course these are simpified definitions and defects can change priority as our understanding of timescales and customer needs progress (these change all the time) but the point is not to try and apply some sort of absolute classification of severity.
Priority and action is all that matters!
One of the important factors in this often debated topic is that you get buy-in from everyone involved. The severities and priorities are just semantic until your group attaches meaning to them. We can have 2 or 2000 categories but what matters is the behavior that it drives. How will management use the statistics? How will the defects drive the risk-management? How will the entire process drive the decision to release or not? The important thing is that everyone agrees on the process and what each level means.
[This message has been edited by vantontl (edited 04-18-2001).]