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.
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-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'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.
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?
screenshot-kcpt19.atlassian.net 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:
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.
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
@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.
You are not. Prioritisation and ranking are different things.
Most people would look at 1100 backlog and simply skim it for the stuff that needs to be done sooner, moving that higher up in the ranking. We don't try to rank everything in one go, as we really only need enough stuff ranked to feed into the next couple of sprints.
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.
did you find a suitable solution?
Our situation might be quite similar ... our Jira project covers SAP changes for the entire group, so many different business units, many different business processes/Product Owners and about 40 IT persons are involved. Also, we organize/plan ourself in 2-week sprints (we call it IT heart beat), so it's not Scrum, it's our way towards agile.
We seek to rank Jira issues by topic (e.g. CRM; EDI; HCM) as we have Product Entry Boards who will define the ranking for their topic/responsability. So, we filter the backlog by specific topic and define the ranking. Since all other PEB teams will do the same, we do not see Jira providing a suitable solution.
Thanks for sharing your feedback, Roland
What I've done is not perfect but works for us. I added a number field to my tickets (or issues) called steakholder priority and we set this field manually (we do this in a weekly meeting with our stakeholders where we review all the new tickets and prioritize them). I then ordered the backlog for the board query by this ranking. The result is that the backlog is ordered how i want them, however we loose the ability to drag and drop the tickets on the backlog to reorder them.
In truth, this is a bit of a pain, as if we want to reorder we need to update the field, however I dont think that Jiras drag and drop abilities is to great. I use it in the sprint boards and it is often lagging and jumping to the wrong places. Also trying to drag issues onto a release or epic as well at times is not so smooth.
So all in all, although maybe not the best solution, but it works best for us.
Good luck @turo
HI @malcolm telfer ,
I definitely share your pain and those of so many other Jira users. Jira functionality is GREAT!!! The tool is HORRIBLE!!
Jira's biggest problem is that they don't have good competitors. There are other similar softwares, but none (at least that I've used/tested) which compare nor have as many plugins which really make Jira a choice solution, and for similar pricing. One day, there will be a competitor and @Atlassian will loose market share. They will become a "Blackberry".
To your issue, see my post above (date Oct 09, 2019) on how I configured to Jira to work for me. Although I loose the Drag & Drop ability on the Backlog, I am able to order the backlog the way I want to (based on a custom numeric field which I added to each type).
You know you could just use ranking to do the same as this custom field?
You can sort by anything you want in a filter, but when you sort by something other than rank, you can't drag and drop - even if you could, you'd be needing to change values of what you're sorting by rather than rank, and the reason you can't is that most fields don't support it because they are not ranks.
In short, what you're asking for here is a logical impossibility. You can sort by anything you want, but only the rank field supports ranking.
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.
Depending on which version of Jira you're on, when you're in the backlog, you can right-click tickets, and it should give you options to move them to the top/bottom of the backlog or to specific sprints. (I only figured this out recently, so I'm not sure how intuitive that is.) I find it helps if I have >100 backlog items and want to move the ticket created most recently closer to the top of the backlog.
Hope that helps!
Being a complete newbie to Agile, I learned a lot from this discussion.
I am curious about why essentially sorting a table shouldn't be possible for any field you want.
You wouldn't be able to *simultaneously* have a single order that respects both priority and rank (or rank within prioirity, as established by the previous discussions), but why would it be forbidden to choose how you want to view the list of issues?
I could imagine starting out with priority-sorted view (or any custom field), and with the only option to change rank being "move to top of backlog" and "move to bottom of backlog" buttons (drag and drop not allowed).
Then go to rank-sorted view, and drag and drop however you want.
This would enable you to "stick everything at the highest priority at the top of the pile [as] a good starting approach on a new project", but then also let you switch to rank-sorted view and fine-tune.
I'm sure this is a naive way of looking at things that is probably either in direct violation of some Agile principle, or would never work in the real world for some reason (clue me in!), but (a) being able to click a column to sort the backlog, instead of having it a fixed part of the filter, and (b) drag and drop enabled only in rank-sorted view, and move to top/bottom rank in other sorted views, seems like it would be useful.
There is no direct way but I think we can achieve it by adding a custom column of Drop down type/Text type (let's call it Backlog Rank) with different values (like 0-6) and then order our backlog based on the custom field.
The same custom field can be updated in automation as well based on whatever criteria we want and based on the custom field value the backlog will start reflecting the new ordered items.
Then how about if we do -- ORDER BY Rank ASC, Custom column ASC.
In this way drag and drop will remain intact and the custom column can be updated with the help of automation. So if we are updating the custom column value via automation based on priority then it will be reflecting in the backlog. This can be used with any automation criteria as well like based on status update etc.
What I'm saying is that definitely rank has its own role but at the same time arranging the work items manually as per our required rank is not very efficient. Also, at the same time automation doesn't allows us to update the rank. To overcome it I suggested to have a custom column which can mirror the behavior of the rank.
There's nothing to stop you doing that, but it's pointless. Your custom column sort would have no effect because each rank can only have one issue in it, so there's nothing to sort on custom column.
A custom column to mirror rank won't work, for the same reason priority is not for ranking. To mirror the rank field, you would need a field that, um, does ranking, like rank.
I think this is a serious issue and I understand the complications, but this is also a cop out.
You could at least put a simple feature in place that would help in 95% of scenarios. A button to "Re-order backlog (or sprint) by priority" - which will do a one time sort for you. As a starting point this would seriously help. You can do this periodically or whenever you feel like it.
@Ron Soffer This will impact the drag and drop functionality on your backlog. If you'll check my previous discussion with @Nic Brough _Adaptavist_ You'll find that such scenarios are already discussed but there is no solution as of now to handle it.
I even tried using automation and calling JIRA APIs to update the ranks but even that can also help on simple conditions and not quite helpful.
@abhishek.pandey why would this impact drag and drog? I don't think you understood my suggestion.
I'm suggesting adding a button that does the sort for you one time, then you are free to drag and drop as you please. This is a feature request to the JIRA team. I'm not sure what you are referring to.
Sort on what criteria and where? The backlog is ordered based on rank. The moment you change the query to show it based on some other field, you loose the drag and drop facility. So, if you want to reorder then it has to be on the basis of rank only. The problem with rank is, you cannot decide a criteria for it and it is auto generated by JIRA itself and is changed based on manual reordering of the work items (issues/tickets). More so over you cannot assign a value directly to rank.
If you're not clear yet then you can try using your own suggestion and see how it is not a feasible option because I'm sure you're just suggesting without trying it yourself.
No, sort by priority, which is what is being asked for... High priority issues being sorted higher.
I never said change a query, I said auto sort ONCE. Seems you are having a hard time comprehending a one time sort. It doesn't persist, or change any queries. And it wouldn't affect drag and drop.
I thought the "one time sort" was clear. I wouldn't want one though, a single click to destroy all the ranking we'd already done is not something I would ever want to let happen. I think I'd only allow for it to happen before the first sprint had started, after that, nope.
It'll be one time sort on priority which mean changing the query. The sorting is done when you use ORDER BY (In this case ORDER BY Priority) which leads to changing the query which is being used to show the backlog. And like I mentioned earlier once you change the query, you won't be able to drag and drop. If you're suggesting to revert back the backlog query based on rank again after changing the query once to show it based on Priority then what's the point of this whole exercise. Basically you're just viewing the list of work items sorted on Priority once, which can be achieved just by going to issues list and listing out the work items based on your own JQL.
Also, as I mentioned earlier why don't you try implementing it yourself, whatever you're suggesting and verify the results.
@abhishek.pandey it's a lost cause. Have a good day mate.
@Nic Brough _Adaptavist_ I hear that. Personally I feel this would be useful for many teams, and even on a per sprint basis you can use it to help organize before manually drag and dropping things into place. For a larger backlog, it may or may not be as useful. I think it would be for many. You can also allow this button to use any number of fields to help you, priority, date, etc. It could be customizable by the user. Just some thoughts.
Project managers know this problem: A “mountain of work” lays in front of you, and you don’t know how and where to tackle them. Different to-dos lie ahead, but just one task after the other can be ha...
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
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events