Do I really need to sort every item in the backlog manually?

I am a product owner and use the backlog every day. People in my company report bugs and submit ideas and I read every item and edit and if good accept them (like most of us usually do). I also add more details to the issues and most important, I set the priority to the item.

What currently happens is that even if I set the priority to Critical, the item appears at the very bottom of the backlog and I have to move it to top.

This seems like a simple operation but it is very annoying to have a priority field that is completely ignored in my backlog.

I have tried to change my filter to order by priority and rank but that renders the backlog unusable as you can't use any of the drag'n'drop features, you can't create sprints etc.

So my question actually is:

Why do you have issue priority if it is necessary to order every single item in the backlog manually?

I would like to be able to rank my issues inside one single priority. This would prevent the situations I have now and that is that I have a new issue, that I have prioritized as High, that is ranked lower than all of my existing backlog issues. And to change that I have to manually drag it somewhere between all medium and critical issues and then so I can rank it compared to other high issues.

5 answers

1 vote

The priority is a JIRA core field.  The Rank is an Agile field.  They don't really play together that well.

Most places I know of either bin the priority or just use it as a guide to inform their ranking, rather than an absolute. 

There's also a logical problem with trying to combine priority with ranking; there's no easy rule for sliding new items in part way through the list.  Consider:

These issues are in your backlog, ranked in this way:

  • xyz-122  Important
  • xyz-124  Critical
  • xyz-123  Trivial
  • xyz-126  Critical
  • xyz-125  Important

xyz-127 is added and flagged as Important.  What's the rule for where it should be inserted?  In this case, I'd say it needs to go in at the bottom anyway, because you've got important and Critical stuff already.  But then let's say xyz-128 is added as Critical?  That's even harder.

I can understand that there are technical challenges, but I don't think it can't play together For your example, my list would look like this * xyz-124 Critical * xyz-126 Critical * xyz-122 Important * xyz-125 Important * xyz-123 Trivial Simply because it would be sorted by priority and then by rank. and then it would be perfectly ok if 127 is ranked last within the important priority. That is what I could then call finer-grained priority.

But that's wrong, because I've ranked xyz-123 above 125 and 126.

I could also imagine that dragging an item with trivial prio to the top would raise a warning: "you are about to change the priority from Trivial to Critical." and would do exactly that after confirmation

But that's wrong because I'm ranking the issues based on what needs doing first. My point is that trying to use two methods to rank one list does not work. If you make the decision that you are going to rank primarily on priority, then you can't really use ranking much, and your best bet is to drop the scrum planning process with ranking and simply go Kanban with priorities as swimlanes.

Well I understand it's not the way it works now but I see it could work like that in the future. Not only that, I can tell you it does work now, I just have to do a lot of things manually where it could just be solved with a different sort order. And changing methodology, just because Jira Agile doesn't support my workflow isn't something I am willing to do :)

No, that's fine, it's just the way you want to do it is one way, and it doesn't work when you're using two ways to prioritise/rank. You need to pick one and stick with it. I suspect you'd like to be able to rank within priority, which would be useful for some teams. But there's no one-size-fits-all solution to this, which is why it's hard to write code for.

If you pick Priority, you can't use the agile board any more. So there is only one way in using it.

Exactly - priority doesn't make sense in Scrum, only ranking does.

I know this topic is a year old now, but can someone help me understand this better?

Rank as described by this Atlassian article, mentions that Rank allows you to prioritise issues at a more granular level and uses the example of if two issues have the priority of 'Major', you can easily give one rank over the other. That makes complete and total sense. However in the example Nic Brough added above, why would a 'Trivial' priority have any type of Rank over a 'Critical' priority? That doesn't make sense to me at all. So if priority is important here, which in the backlog it seems to have no use at all, correct me if I'm wrong, but to me it would make sense to be able to Rank issues within a priority group.

Currently we aren't using a Scrum process since Kanban works better for our company. The backlog is where all user/client tickets go when they are made. When we have our team meetings, we go through the backlog, and select all the issues we are going to develop. It would be much better if we could sort by priority (even rank within priority), however when we filter by priority, we can't even drag issues to the next step of our workflow (Selected for Development). We would have to click on every issue one by one to move the issue to "Selected" which takes time.

If sort by rank within priority group can't be done, is there a way we can at least be able to drag and drop backlog issues to our "Selected" workflow? 2016-09-20 09-59-16.png

>why would a 'Trivial' priority have any type of Rank over a 'Critical' priority?

Imagine this simple case:

  • xyz-123  Trivial
  • xyz-126  Critical
  • xyz-125  Important

If xyz-126 cannot be fixed without xyz-123 in place, it must be ranked lower.  Rank and Priority do not measure the same thing - priority is about how important it is, but says nothing about time.  Rank is how important it is relative to the rest of the list and hence when it needs doing, relative to the rest of the list.

Ahh, ok that makes perfect sense, time is a very important factor. I didn't connect time with rank. Thanks for that. 

I guess it isn't completely necessary, but what do you think about a feature that groups backlog items by priority and using rank inside of each group?

That function might help some people with getting started on ranking (and initial "stick everything at the highest priority at the top of the pile is a good starting approach on a new project) , but it's pretty much useless in real life once you start work.  Because you often need to rank things in a different order to priority.

That makes sense, because that's basically where we are. I just got my team on Atlassian a couple months ago, and it's been so great to us, we are planning on expanding to the entire company. But of course we are still pretty new to the Scrum/Kanban process, hence being more concerned with priority I guess.

I'm pretty deep into the workings of JIRA now, and I have completely customized it for our workflow. Do you however have a recommended read I could check out to take our planning process to the next level?

Thank you for your help.

As stated above, the rank is an 'agile' field whereas the priority is a core field.

Importance and actual planning and sequence is something completely different. Using agile means you are working in sprints most likely and you plan towards a given timeframe say 2 weeks.

If you have 3 important things taking 4 days in time each and a few trivial tasks taking 2 days. To fill up 10 days towards a new release you would rank 2 important tasks of 4 days and 1 trivial of 2 days instead of starting the 3rd important task, since it wont be finished and you can ship something additional. 

etc. But I think you already got the point smile



@Jeroen Mares @Nic Brough [Adaptavist]- In our usage, priority is not importance.  ("Priority" comes from the word "prior" which literally means which item you'll do before the others.)  For us, importance / urgency / severity is captured in other fields.

To me, it makes perfect sense that you could use the Priority field for coarse-grained rankings, then drag and drop within a priority level.  Seems like a very useful feature.  I suppose you could get there with N different backlogs.

I would also like to have the feature of a second ordering field inside of rank via priority. But as stated by @Jeroen Mares it is not really practical to always sort the backlog this way.

I have the exact same use case as described by @Jasenko Ramljak and would say it could be solved by adding a "Sort to top of active sprint" and "Sort to bottom of active Sprint" button. Just like the "Sort to top of Backlog" and "Sort to bottom of Backlog" buttons. 

I actually have a custom field named Business Priority which is a number field.  This value is set after backlog review\prioritization with various Business Units.  I need to be able to order my backlog using this field (JQL = .....ORDER BY BusinessRank).

Why after so many years and users requesting this feature, has Atlaassian not figured out a way to build the software to support this level of customization??????????????????

I thought the same thing after reading this discussion thread. I've been looking for something similar in our version of JIRA. Seems like something that, even if it's not the recommended approach to scrum, should at least be configurable if that's how teams wish to approach the backlog.

Like 1 person likes this
0 votes

I would like to have the possibility to sort sprints by rank and backlog by priority.
In this way, I could easily and precisely adjust the order of the current/next sprint and still see the tasks with highest priority when planning the next sprint(s).

0 votes

You can do this, you just need to go to your Board Settings -> General and change your Filter for the project.  This will disable Rank sorting, but will allow you to sort it in any way that you wish. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 29, 2019 in Jira Software

Transforming Jira Software projects for general project management purposes

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....

178 views 0 6
Read article

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