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 pointDo 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?
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 
It works great and does miracles by itself ^^
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 -
That’s the way I see it from over here in the cheap seats, anyways
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.
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.
Just came accross this existing thread before starting a new one 
It’s about the topic about bug severity and kind of connects to @simplysanne 's LinkedIn posting…
I wrote a blog post after I was asked „What do you do if there are conflicting views on bug severity in software testing?“ via LinkedIn and turned them into my 6 tips/hints on what to do if there are conflicting views on bug severity in software testing.
I do like all the thoughts and discussion also above in the comments.
Next time, before hitting publish on my blogpost, I should consider searching MoT Club threads for inspiration… 
I could also think of a follow up 
blogpost.
But while reading again and again:
and repeating in while talking or singing I thought of the Songs-thread 
This is an endless discussion and there is not much of a point for hot arguments and debates 
generally speaking, the formal descriptions are exist and more or less standard. If you don’t have a very strict and formal dev process where the team uses particular attributes of tickets that can’t be quickly discussed and adjusted (I mean in minutes) then maybe this is important but for most modern tech/IT companies this is unlikely the case
If we speak about any more or less urgent tasks that can’t go by “ordinary” flow (that is used by the team), something like that (simplified): ticket with requirements/description → grooming/planning/estimating → fix version → development during selected sprint + testing → shipping, then the team with stakeholders discuss the impact and urgency, discuss risks and affects on the current plans/sprint/iteration/other features, estimations, all thing are taken into account and there is an approximate due date when the feature/bug fix will be delivered (and details such as when development will start, when the feature will be ready for testing, whet testing will start and testing estimations, etc). Usually, it takes no more than half an hour to get to an agreement with the team - the due date that satisfies everyone. As simple as that, this works and this is the most efficient way.
If you want to spend time on very formal and slow procedures, then lose your time and resources, and company money with heated discussions about the differences and values for severity, urgency, and priority of bugs then, of course, you can introduce the whole document and process that will describe the difference to the smallest details but it won’t help business or users to solve their issues, and it won’t help devs and testers to work more efficiently
Tracy Archibald (@tracy_a31) and Leah King shared some handy diagrams during the Leeds Testing Atelier.
I’ve only once worked in a place where software could easily kill you. Users ignored the warning labels, but that’s another matter altogether. However talking about the economic impact, and using past experience of the impacts is super helpful when it comes to deciding which issues to address first. Especially when addressing too many issues at once can also create user friction that any change tends to cause. I love the concept of “consequence” versus “likelihood” to drive proper risk mechanics understandings in teams, even if a bug never gets explicit scores in each, team members really do need to grok how we arrive at a rating of “High”.
