We too have been using Jira for a few months and generally are quite happy. However, Bugzilla has it right, IMHO to have separate Priority and Severity settings.

Severity = how bad/tough/gnarly is it?
Priority = how important is it to do?

A misspelling of the CEO's name on the help.html is "TRIVIAL" in technical terms to fix, and causes no issue for anyone using the application. But it is of "URGENT" Priority Level 10 so it is fixed before the CEO sees the bug!

The Jira help pages even contradict themselves a bit...

"An issue has a priority level which indicates its importance."

That is correct. Something with a high level of priority should be the first thing to be addressed in the queue.

However - the descriptions of the options are all severity levels.
Blocker
Critical
Major
Minor
Trivial

Would greatly appreciate some offical response on this feature... do we just need to drum up more votes in support of the addition?

Thanks!
Tim

issue.field.priority = Priority

and change Priority to Severity.

A separate Priority custom field could be made.. but this feels like hacking up something that should be a core feature. Marking for 2.6 so we can get a decision either way.

Wondering where this stands folks - it's still a stumbling block for our group.

I still find it hard to understand why this isn't a "DOH! That makes sense." kind of thing.

Timo

I can improve slightly on Jeff's idea and use the existing system to provide exactly what I need. I can re-define the existing 'Priorities' to be real priorities and add a custom field for Severities for bugs only. The whole thing then hangs together beautifully and doesn't need hacking. However, I'll be cross if this then becomes a core feature in a month's time after all, unless a bulk edit feature allows easy migration.

Cheers,

Mike

As a long time JIRA user I'm now used to this, but I've had more than once someone ask me why the JIRA priority levels really sound like they are severities. And as a followup question: Then where are the priorities?

Switching from priority to severity in JIRA would most likely cause confusion. So it seems like adding a severity field would be easiest

In our JIRA setup we actually use two additional custom fields: Urgency and Importance (this is the Eisenhower principle). The JIRA Priority value is then a function value of our two custom fields. We seldom change the Importance but as time goes we might raise or drop the Urgency of an issue.

Regardless of our setup I'd feel more comfortable with both a Priority and a Severity field in JIRA. Custom fields are after all just second class citizens.

The workaround of a custom field, as Knut pointed out, really is a second class citizen.

Separate Priority/Severity settings is one of the few things that I miss from Bugzilla.

It is so important to know the difference between the two.

Take THIS case for example. How could you guys let a "MAJOR" PRIORITY issue (with RED UP ARROW to move this to the TOP) be left idel for almost two years? (Created: 08/Oct/02 05:05 AM )

The "MAJOR" priority setting is bogus.

SEVERITY is LOW
– renaming a field, and adding one new core field.
– since the system is not crashing currently and because the req'ts are minimal – it's LOW severity

However...

PRIORITY seems to be LOW for Atlassian.

Tim

Field-level permissions would be great, in our workflows:

Developers would edit Severity
(Bug testers might not understand the scope underlying the issue)
Project Manager would edit Priority.

That way Developers can look at their dashboard and know what they should be working on – i.e. Top Priority items – ex. P1 then P2 then P3 then P4 then finally P5.

TLC

For those who don't know the history, let me let you in on a little secret. Originally, JIRA did have a priority AND a severity field. I believe the second was removed around 0.7. Why? Why? I hear much wailing and gnashing of teeth in this thread!

For a number of reasons actually, but principally because it was confusing to business users. To a software developer, it seems obvious that the severity of the bug ("The system crashes completely") is unrelated to the priority of it ("There is a one in a million chance of this occurring"). However JIRA succeeds so well because business users can actually use it (unlike Bugzilla). If you present a business user with these two fields, they are instantly confusing. Hence why it was removed in the first place.

I do believe (as can be seen from the software developer comments above! ) that two fields are useful in a lot of circumstances, but I'm still not convinced this should be a core JIRA feature. Custom fields are slightly a second class citizen at the moment (although I believe with 3.0 this will be completely fixed) but you can still make them required and order them (with field layouts), put them on your filters (with column layouts) and indeed search and filter them (in the navigator).

What is a good reason to add it as a default field then?

Cheers,
Mike

Lol. Okay, now that we know the history... and the roadmap for 3.0 – I'll back down and say, "Good 'Nuff for me".

(Heh heh, now I just need to open a case to get Mike to explain the history on why a "Task" type issue doesn't have a "Completed" resolution option but does have a "Won't Fix" and "Cannot Reproduce". <grin> )

Thanks Mike & Mike,
Tim

IMO the two solutions to the problem at hand are:

• don't change anything
• add field-level permissions as Jeff proposed

If the latter approach were decided upon then this issue would probably get a HIGH severity (As if this discussion isn't confusing enough already). Then for example

• business users could view/edit priority only
• developers could view priority and view/edit severity
• and reporters view priority and set severity

But I assume this kind of fine grained permissions isn't planned for 3.0 (thus a HIGH severity).

Cheers,

--knut

I think it would be a great shame to not fix this, as it seems so fundamentally incongruous. I know that you can change fields, add custom fields etc etc, but the fact is that "out of the box" the interface does not make sense.

From a language point of view, a 'Priority' ranges from 'Urgent' to 'Wish' or simply 'High' to 'Low'. I never heard anyone describe a priority as 'Blocker'. Moreover, the listed options and help definitions just don't apply in the context of any issue type except 'Bug'. We in fact tend to find that this discrepancy is confusing to our business users.

If the 'severity' field was left out to avoid confusion I'm afraid I cannot understand why the 'priority' was not kept as a simple high-low scale. A developer can easily gauge the severity of a bug for himself from the description and recreation, but obviously cannot know how urgently the customer wants it fixed.

So my conclusion after nearly two years (yikes!) is:

1. Rename the default priorities from Blocker-Trivial to Urgent-Wish (or High-Low) and leave it at that. That way Jira hangs together nicely out of the box and we do away with this horrible mismatch.

2. Two fields are only useful in the context of bugs, and even then the severity is not all that revealing except perhaps for search purposes. I would therefore not dispute that there is not a good enough reason to add severity as a default field. If people want to add a custom field for bugs to indicate severity as well, then that's fine.

I know I can do these myself and intend to do so once the case is closed, but I'm sure this must gnaw at the Atlassians' sense of elegance and correctness Am I right or barking up the wrong tree, or just barking? Go on, you know you want to!

Cheers,

Mike

Mike – I'm in full agreement on those points.

Our biz users seem to pick "Major" for all bugs. <grin>

However, they are conditioned to "Priority Levels"... because application support is assigned a level from P1 to P5. 1 being highest/fastest to respond or fix.

So like you, I will rename the values (P1,P2,P3,P4,P5) and add a custom severity field for Developers/PM's to populate.

(After the purchasing dept. obtains a license for us, since the JIRA eval ran out 3 days ago and is now in read-only mode.)

BTW - I suspect that even though the out of the box Priority values seem like poor choices to a few of us, most people apparently are not complaining, and I doubt Atlassian could come up with values that would please 100% of the folks 100% of the time.

So kudo's to Mike and the Gang for making it easy to change them.

(And I just realized embarassingly that if this was such a big deal for me... why hadn't I changed the values a long time ago? Doh!)

Timo

1. I think Jira is an exquisite incarnation of software development and really want it to be 'just so'.

2. I'm a total pedant

As you say, Tim, if most people don't care enough to add their voice then so be it. I'm sure there would be plenty of complaints if the guys changed it!

Keep up the good work guys - can't wait for Jira 3!

(Why not follow Sun's lead and call it Jira 7

Cheers,

Mike

Putting both priority and severity into a single sort order makes life easier when you're planning a release.

Especially with the opportunity cost of other more important bugs not being fixed, I am happy to see this one left alone.

Nice to get this closed off after two years I will sort us out with custom fields as appropriate, and look forward to the virtual custom fields to implement the RPN - great idea.

Thanks chaps,

Mike