Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Remind me why Jira removed the Severity field?

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?

2 answers

2 votes

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)

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.

Like Shana Johnson likes this

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.

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.
Like # people like this

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.

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. 

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)

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

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)

But everything is subjective! Quoting Albert Einstein.

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

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...

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you