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.
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.
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.
I think you're missing the points we're making.
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.
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 ...
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!
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