Severity vs Priority vs Urgency vs Impact of Software Bugs

I saw this on LinkedIn from @simplysanne and love the language and the simplicity of the words.

Severity vs Priority vs Urgency vs Impact
Having a heated discussion about the differences and values for severity, urgency and priority for bugs.

You see I think all you need is:
fix yesterday
fix ASAP
fix soon
fix at some point

Do you agree? If not, tell me why I’m wrong?

What do you use in your current project?

If you could wave a magic wand, how would you change it?

6 Likes

Interesting!

We use Impact, Probability which will lead to Severity and Priority.
We use a standard impact/probability matrix to access our needs and then it will get a severity for example medium, low high etc…

The priority is based on other bugs/user stories, which to be fixed first.

I get that BUT in order to get to the “fix yesterday” or “fix ASAP” you need the impact/probability.

Not a single thing :slight_smile:
It works great and does miracles by itself ^^

1 Like

I think its a matter of semantics. Priority/Severity, Urgency/Impact all samey same as far as I am concerned. What is critical is that everyone involved understand what those things mean to the team and how the defect/bug/incident report is treated. Throughout my career I have used Pri/Sev

Obviously P/S of 1/1 means its product breaking and is affecting the product, users and probably the company in a negative way. Or will do so if that defect is shipped.

And likewise a P/S of 4/4 is so minor as to likely not get fixed soon or ever.

The nuances are in the other combinations.

A pri1/sev4 might be: oh…the product completely fails for the CEO when he uses his favorite browser that almost no one else uses.

And so on. But the words dont matter. It could be a set of verbs, colors or even animals.

The important thing has always been -

  • the team knows what these thing mean to them and their work.
  • The values are not etched in stone at creation. Triage can and often does change them.

That’s the way I see it from over here in the cheap seats, anyways

3 Likes

Gerry Weinberg advocated just two options - will fix and won’t fix - and I would think twice before disagreeing with him.

In my view, testers should only express an opinion on Impact, and they may not even be competent to do that if there are effects beyond what they can see or are aware of. Everything else is the responsibility of the product owner. I personally refuse to to assign Priority or Urgency and I instruct my testers to do the same. If they are forced to assign Priority, I tell them to set all issues to the same value (I don’t care what value).

For bugs that are going to get fixed, priority should be set to maximise developer efficiency unless certain bug fixes must be released as soon as possible. Both of these are factors that only the developers and product owner can assess.

And to echo Michael, bug triage is really important. People who like to manage by numbers are doomed to fail (and I’ve worked for more than enough people like that).

While urgency is important, its just one piece of the puzzle.
Severity, priority and impact are equally crucial factors in bug management.

Our project utilizes a comprehensive approach that considers all these aspects to prioritize effectively.

If i have my magic wand, i could change - to ensure clearer guidelines for evaluating bugs, streamlining the process for smoother operations.

1 Like

Is it important, how important is it, is it more or less important than this other important stuff.

A simple Priority like that can work, sure. It depends on how important it is for the company’s or team’s context to be formal about the underlying step of considering the likelihood and severity of impact on the most valuable customers and the ease of fixing.

What I’d want to avoid is turning bug tickets into carefully curated documents that are diligently categorised and recategorised, estimated and re-estimated, rechecked to see if they’re still relevant, and reported on until the heat death of the universe. We want to get rid of bugs, not enshrine them.

Personally - on the other extreme - the most delightful way of working has been that 99% of bugs are either detected and fixed straight away during pairing sessions or added as code review comments to be fixed straight away rather than backlogged. With the remaining 1% getting logged in a lightweight way and removed after six months. I understand that’s not possible in everyone’s context.

1 Like