Remind me why Jira removed the Severity field?

[Bar T]

I still have some team members asking for the severity field. Some old articles linked here don't come up. Can someone remind me why it was removed?

[Nic Brough -Adaptavist-]

Because every Bugzilla that Mike and Scott ran into had a severity field that contained utter rubbish.  They dumped the field because it was (and still is) usually useless.  I still work with systems where it's built in, or been added, and that still stands.

It's not that the idea of a severity is wrong, the problem is that to a human raising issues, the severity is not quantitative, it's subjective.  Every issue is "severe" to the person raising it. 

Consider a simple case:  My cat is ill.  That's critical to her, very important to me and the vet that I take her to, mildly upsetting to the neighbours and friends who like her and utterly irrelevant to the rest of the world.  What severity would you choose?

Severity was dumped because it's subjective and hence useless.  When you do think you have a need for it, use a custom field to gather the information, but quantify it, or better, replace it with a proper measurable set of fields - Impact (how many people affected) and Functional loss (trivial being something the wrong colour and critical meaning the application just crashes so it's totally broken)

[misha_d]

Your QC requirements should describe Severity statuses for bugs. For example, 'Highest' severity for core functional, 'Medium' for secondary functional, 'Low' - UI, 'Blocker' - obviously crashes, stoppers etc. Meanwhile priority should be defined per task by one responsible person/group.

[Nic Brough -Adaptavist-]

Nope, that's a priority, not a severity.  And you still have the problem that it is subjective and hence generally of no use.  By all means capture your descriptions in a field, but do not call it "severity", because it's not.

[tymofii.tovstyzhenko]

Nic, let me answer your example

1. how objective it is - it may be based on a risk analysis. Such an approach is more or less objective. Even if it's subjective, but set by one person named PO consistently - this is acceptable.

2. My understanding of your example about cat:

• Severity: in your example product is "Things in MY PERSONAL life". In your case life of things close to you is under high risk and you start being overloaded by this, so severity is from High (if you are 40 years old) to Critical (if you are 5 of 65 years old)
• Priority: imagine you are 40 y.o. (so severity is High) and you are fired a month ago, so you have no money and today you have a very important interview; moreover your wife is going to give a birth today or tomorrow. This means you have at least 2 very important stories in your product "Things in MY PERSONAL life" in the current sprint. So issue with your cat will have priority from low to medium. You even can let him die.

[Nic Brough -Adaptavist-]

I'm afraid you have completely misunderstood the point.  The severity of my cat's illness is critical to them and irrelevant to most of the rest of the world.  You can't judge any of what you've said without looking at the different points of view.  The priority is something the developer (the carer for the cat) will set, and your priority calculation is incorrect for them as well because your severity is incorrect because you are the person guessing at something you don't really grasp because that's what severity is usually set up as.

The point is the severity is a poor attempt to recognise something that is too subjective and should really be calculated from objective, quantified values that means something to everyone involved.  And that's why Jira does not have one by default - most people don't understand it.

[Iuri Pereira]

Severity should be considered for bugs. It is clear that we are dealing with two dimensions of the problem which are how fast I need to fix the bug (Priority) and What is the impact on production (Severity). That said we should consider Priority from Low to Highest for example and Severity from Low to Blocker. Like that:

Priority:
4-Highest: Should be fixed immediately
3-High: Should be addressed quickly for some reason, a unexpected bug of deadline of the project
2-Medium: Errors that could be addressed to future sprints
1-Low: Errors that does not affect functionality

Severity:
4-Blocker: Tests are not executable, crash or feature is not working
3-Critical: Feature is working poorly
2-Medium: Feature does not match some acceptance criteria
1-Low: It does not affect functionality (UI in most cases)

The most important thing to consider is that you could have problems that need to be done ASAP (priority) but that are not critical to the system (severity). In most cases, a Blocker severity means Highest priority but not always. I believe that with these two dimensions you could work better to address bugs to be solved accordingly to reality. 

[Nic Brough -Adaptavist-]

That scheme might work for you, and you can do it with a custom field.

But it doesn't change why the severity field was removed, and it's definitely no reason to add a system field for it (that most of us would then have to get rid of again)

[Iuri Pereira]

I found an article about incident management that shows the importance of severity levels if you willing to use it

https://www.atlassian.com/incident-management/kpis/severity-levels

[Nic Brough -Adaptavist-]

Still no reason to build it in.  As I said, if you want one, add it (and reserve its use for the people who know how to use it)

[Amir]

But everything is subjective! Quoting Albert Einstein.

[Nic Brough -Adaptavist-]

I think you mean "relative", which is not the same as subjective.

[Bar T]

Thank you, seems to make sense when at the end of the day the question is "what should be fixed next based on priority".  One of our teams wants to use "fix priority" in addition to "priority" - hoping that works in terms of "fix priority" for a given sprint...