When will we have "Severity" as a default attribute in JIRA. Ideally "Priority" should have values such as "High", "Medium" and "Low"


2 answers

3 votes

Never.  Atlassian deliberately removed it from JIRA very early on in it's life as it wasn't helpful.  See https://confluence.atlassian.com/jira/why-doesn-t-jira-have-a-severity-field-like-bugzilla-192840.html

As Steven says, if you have a need for it, it's very simple to add as a custom field.  And you can always change your priority list too.

1 vote
Steven Behnke Community Champion Feb 03, 2016

You can create Severity as a custom field in JIRA. What value do you see in there being a default field called Severity and how would you want this implemented? How would you use it?

Consider reading Atlassian's blog on the subject – http://blogs.atlassian.com/2014/06/organizing-issues-priority-optimize-delivery/

Hi Steven, I understand that one can create any number of custom fields. The reason I suggested default is that it should be out of the box. Severity usually has the values such as Critical, Major, Minor, etc as is currently assigned  to Priority.

Before JIRA, all defects tracking systems, home grown or commercial have followed this principle. It simply makes logical sense to do so.

Like 1 person likes this
Steven Behnke Community Champion Feb 03, 2016

But JIRA has Custom Fields out-of-the-box? What's the use-case for built-in severity vs custom-field severity? Not trying to be combative, I'm genuinely curious of why being out of box is important when fields are simple to add.

That's why I was curious as to your implementation desire – If the field is implemented in a useful and functional way perhaps it could be added back in. I've worked with teams that used it in Bugzilla and use it in JIRA. Most teams do not care and don't ever ask about it though.

I'd be hard pressed to believe the Product Management behind JIRA would add that back in as a system field, since as Nic links and points out they have a page detailing why they removed it.

The Severity field was removed for a number of reasons, but principally because it was confusing to business users.

In order to re-implement Severity, you can create a select-list custom field, order it (with field layouts), put it on your filters (with column layouts) and indeed search and filter it (in the Navigator).

Given that JIRA is used to track both requirement and defect this distinction becomes very important.

User Case #1 (defect):

When logging a defect one would use SEVERITY (what is currently called priority in JIRA) to indicate the impact of the defect. The PRIORITY field will most probably be not filled by the defect reporter (QA team) but by the development manager to help developer decide the order that should be followed to fix the defect. For example, if there are 20 "Major" defects and one can only fix 5 then which 5 should one tackle would be driven by their priority. 

Use Case #2 (requirement - story or enhancement):

Most of the time one would ignore the SEVERITY attribute when dealing with requirements but focus on PRIORITY field with values such as high, medium, low. Again, here it is being used to help decide on the sequence in which these should be taken up / what can be moved out from the current release if all the features can not be accomplished in a given release timeline.

I hope this provides insight around how these fields would / should be used.

Like 2 people like this

I think you're missing the points we're making.

  • The vast majority of users do not use Severity
  • It's a lot less useful in Agile, because your dev teams will be ranking based on the actual content of an issue, rather than a perceived severity
  • Atlassian chose to remove it because it was (and still is) confusing for most users.  I tend to agree with this - I can't think of a site that uses it usefully - in the couple of places I've been where it is used, it's effectively got rubbish in it because the users simply don't understand it.
  • Most places that do have something similar actually do it in human friendly ways - severity is useless, but if you offer the reporter "number of people affected (with values like 1, 2-10, 11-100, >100 for example)", you get a much more accurate and useful metric which you can use for working out real impacts.
  • In the time it's taken you to detail your edge cases, you could have added it
Steven Behnke Community Champion Feb 04, 2016

Sorry Sanjeev but you're not going to convince us Answers users otherwise. It's easily added as a field. You presented zero application functions around this severity concept, instead talking about methodology. 

It can be implemented in minutes and used as you suggest as a Custom Field. I'd personally prefer Atlassian never reimplement it.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

376 views 6 0
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you