It is by design - when Mike and Scott were writing "something that works better than Bugzilla or its competitors", they actively decided to drop Severity because people creating issues almost always got it wrong, and it was not of any real use to developers.
With the provision of custom fields, the people who do find it useful can add it, and should when it's useful for their processes. But it should not be pre-defined - most Jira users don't need or want it.
That makes sense, @Nic Brough _Adaptavist_ , but I do wonder on why they chose to call the field Priority and not use the term Severity.
Considering that the Priority field values are Major, Minor, etc., people rightly consider that to mark how severe (impact) the issue is.
Priority, meanwhile, relates more to when an issue should be handled, which can be managed by using the backlog ranking, Sprint value, Fix Version, etc.
Priority and Severity have very different meanings in English, and I think you have completely understood that.
Severity = how bad is it
Priority = how important it is
Atlassian went for Priority and dumped Severity simply because humans don't understand either of them, but Priority is easier to explain and more useful for sorting.
In fact, neither of these should be presented to the person raising issues. They're always going to over-rate them. Priority should be determined by the product owners, and feed into how they rank it. Severity is useful to know, but is usually highly subjective and needs to be balanced against Impact before it has a lot to say.
Think "Severity = system unusable" - yep, very severe. But that's utterly useless without a scale - "system unusable for one person" is severe, but a low priority (and hence rank) when the other 49,999 people in the organisation can use it, it really isn't a priority when the other issue is 20,000 people can't see some information because it's the wrong colour in the display.
Great points, @Nic Brough _Adaptavist_ , which I agree with.
Indeed, one of the things we do at my work is have regular Bug review meetings to come to agreement on how bad something is, how important it is, and when we think best to dedicate time to fix and verify it.
Thanks for always providing quick and informative information and food-for-thought here in the Atlassian Community!
@Nic Brough _Adaptavist_ I disagree about severity. I think it is useful to have the reporter say how they perceive the severity. Then if you get lots of issues about the same thing you can see a trend in the user's perception of severity. I agree not presenting priority on the create screen because, as you said, they will overrate it.
I've found it to be completely useless because different people judge it differently. That improves when it is explained properly, with a clear set of options that are not arguable, but most places don't do that.
We shouldn't have to be judging a user's perception (in fact, I don't care about their perception in the slightest), they should be giving me absolute data so I can work with it. A list of options should be clear enough that you can pick any random issue, and have everyone agree with the severity on it. Where it does work well is where it's then used to drive a priority calculation, hand in hand with an impact assessment.
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