Severity/priority/urgency

In order to classify a defect, or an incident severity and priority parameters are critical, and are not critical because they are defect and can impact  our KPIs :) , but to be effective and more efficient. The noise around the issues that impacts our users but are never fixed, the feeling of our customers that must contact user support to fix their problems continuously are the consequences or a "bad triage" or of the no understanding of these parameters.

In terms of severity I find quite useful the TL9000 definition and in terms of priority I prefer the "urgency" definition of ITIL (severity*priority)

But mixing all those fields in the bug report is usually confusing as both have default values and at the end you can find teams that are ruled by severity and others by priority, and in most cases I found priority and urgency are used in the same terms.

So, how can we simplify that without loosing information?

Reading the last Michel Bolton entry about severity he define the "Uncertain" as a severity value that is applied to those issues that are not easy to analyze. Also he point out the idea that is quite difficult to know exactly the severity of the problem based only on the symptoms, so the first approach of the severity set is a "guess".

Also "severity" a subjective value, is not a property of the problem as depends on the person who is evaluating the problem (tester, developer, manager, product owner), as many parameter impacts on that (number of users affected, project phase, deadlines, market priorities, etc), so although we based in a objective definition at the end is a subjective value.

Then the priority. Priority depends on product owner, and manager, and tester, and the developer, so it's also a subjective value and also is influenced by the severity level.

• Developer: if the code is new I want to fix it as soon as possible, as it's easier to solve
• Tester: if the new feature has less issues, my job will have a better recognition
• Manager: cheaper to fix recent stuff
• Product owner: take into account if the fix is worthy, what is the impact to the users, and the status of the feature in general.

And urgency at the end is the "deadline" we have to get it fixed.

So, let's  try to define the guidelines for testers about how to manage that in an effective way.

---

PROPOSAL 1

1. Severity 

Severity can be set to: No significant impact, big impact  or undefined 

• Big impact issues should be directly scaled to product owner and manager to take the decision about the Urgency. Just to discard that we have a very urgent issue.
• No impact issue can be moved to the backlog. With a suggested priority, but unreviewed
• Undefined issues should be analyzed more in deep together with the developer and should fall in one of the 2 other categories.

2. Urgency

Urgency is updated taking into account the previous actions, and can be used by the developer to prioritize his work.

---

In this case we have the information severity provides, that will help the team to learn, and the urgency as a significant value mapped directly with the amount of resources and response time expected by the team.

What proposals would you suggest?