I recently had the chance to overhear two groups arguing about the priority of a defect that had gotten out into the wild and caused some trouble. “It was a Priority 3 defect”…”It was still a Priority defect…” went the debate. In other words, this group had 3 levels of defect labeled Priority, with subtypes 1 through (at least) 3. What does Priority 3 mean, or Priority 1, for that matter? Evidently, it wasn’t clear enough.
A quick look on the internet turns up this page on priority. It goes into detail about the difference between priority and severity, but frankly, I don’t think it’s all that helpful of an explanation. Unfortunately, it also defines priority as ranging from P1 to P4. It then goes on to give explanations for what they mean. So why use the label if it’s meaning isn’t obvious? There is no justification and you should stop using it. Pick obviously meaningful names for your priority levels!
As the article states, the priority is usually a judgement call, and it was a wrong call that led to the discussion I overheard.
So what about severity. Surely, its meaning and derivation should be obvious. The article goes on to explain 4 levels of severity. Coupled with priority, that’s 16 different combinations. This is too much. You want to use as few severity levels as you can–start with 2; a primary use case is impacted, or a secondary use case is impacted. A primary use case is one of the 20% that generate 80% of the value. Everything else is a secondary use case. I know what you’re thinking: “But what about defects that cause crashes versus defects that…blah blah blah”. If a primary use case is impacted, what difference does it make? Creating too many buckets just masks the fact that you have a quality problem, and causes confusion for no real gain.
Next, look at isolation: Is this defect in production code? The answer to this question, coupled with the severity, should be enough to tell you what to work on next. The farther out a defect has escaped, the faster it should be fixed. By farther out, I mean that it is impacting other teams, with the customer being the “farthest out” a defect can escape.
Think hard before adding additional categories or making your prioritization more complicated, because confusion can be costly.