Synonyms?
Some would say yes. I scream NOOOOOOOOO!
Severity and Priority are really two completely different concepts when it comes to managing defects. Let’s take a quick look:
Severity defines the impact that a given defect has on the system. A severe defect may cause the system to crash or invoke the dreaded blue screen of death. I don’t think anyone would argue about its severity. But how did it happen? Did it take an obscure set of key strokes or does it happen anytime the uses presses “e”? Or does it only happen only in the month of June, during sunspot activity? What about a spelling error? Or maybe the text color is a really annoying neon green. Severe? Probably not. Maybe just a cosmetic issue.
Priority, on the other hand, defines the order in which we should resolve a defect. Should we fix it now, or can it wait? How difficult is it to resolve? How many resources will be tied up by the resolution? Let’s look at our two previous examples. Issue 1 (system crash) is definitely severe, may be difficult to resolve, but only happens rarely. When should we fix it? Contrast that with the second issue (spelling error). Not severe, just makes you look bad. Should be a real easy fix. One developer, maybe 10 minutes to fix, another 10 to validate (if that). Which should get the higher Priority? Which should we fix now? I’m going to recommend fixing the typo immediately, and if there is sufficient time, fix and resolve the blue screen before the next build. I will probably wait until the next major release. It becomes….a Release Note!
Many commercial defect tracking systems have either Severity or Priority. Some may have both. Sadly, I know of only one. But others allow you to modify existing fields or add additional fields. Of course those are severely lacking in other areas. The perfect defect tracking system does not exist – yet!
Bottom-line: you need to define both Severity and Priority for your application, and based on your user’s needs. Rarely is an “out-of-the-box” solution adequate.
BTW – To solve this dilemma, I am building Dave’s Perfect Defect Tracking Tool, code-named Unicorn. Why “Unicorn” you ask? Because, like unicorns, I have heard they exist, most people can tell me what one looks like, but I’ve never seen one. Unicorn will be fully compatible with Dave’s Perfect Test Management System, code-named “Bigfoot”. Stay tuned!
The Software Entomologist 
I’m not sure if I totally agree with you, but… that’s my nature! I always find a way to disagree. I know I keep saying I’m going to blog about the Matrix and I’ll do it today. Really! It’s nice that you have this post out here so I can reference it. You can come comment after I put up my post and we’ll have a healthy debate. In fact, maybe we can even have a snarky bicker-war, since that always tends to drive a lot of blog traffic!
By the way, check out this post I made awhile back: http://yvettefrancino.wordpress.com/2009/10/21/high-severity-typos/
Some comments at the end about priority and severity. Still a source of confusion in my mind.
With your definition, if something is a “high” priority, does that mean it’s “easy” to fix? In the Matrix, the “easy” stuff was at the low end of the y-axis so I wasn’t clear if that meant it was high priority or low priority…
Per the Matrix: High priority (Priority 1) is both easy to fix and important to the customer.
High Priority (as defined by the Matrix) is both easy to fix and important to the customer
By the way – the typos in your post – definately High Priority. Low Severity, but Wicked High Priority
Let me make sure I get this right since I’m preparing for my blog post…
I thought in your presentation about the Matrix, Severity was importance to customer (as in 1=most important to customer and 4=least important). Priority was ease of fixing (as in 1=easiest and 4=hardest)
S=1, P=1 would be what should be fixed first and S=4, P=4 is what should be fixed last. But what about the middle numbers? Does you fix in this order:
S=1, P=1
S=1, P=2
S=1, P=3
S=1, P=4
S=2, P=1
S=2, P=2
etc.?
I seem to remember you saying you kind of use your gut instincts for those in the middle and just use it as a general guideline for determining order of fixing defects. Is that right?
Priority depends on the Quadrant in which the defect falls based on Severity and Resolution Difficulty. There are 4 quadrants, therefore 4 possible priorities. Priority is the result, not an input. Hope that helps.
OK, that makes more sense….
So… Severity=How important it is to the customer and Priority=Quadrant (ie. combination of how easy it is to fix and how important it is to fix)? Is that right?
Perfect! Couldn’t have said it better myself.
I like the idea of “unicorn” & “bigfoot”!
What would the “Nessy” tool/process be (after Loch Ness monster)? Perhaps the Perfect Automation tool/process.
I like it!
Is the unicorn and bigfoot – tools available online ?