You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Join now to unlock these features and more
The backlog is ordered by default by rank and we have the rank functionnality to have the drag n drop functionnality.
But is it possible to sort by rank ASC and by priority DESC and have the drag n drop functionnality ?
because when we add the priority sorting we don't have anymore the drag n drop.
Ordering by Rank ASC is a requirement for the drag&drop to work; no workarounds for that.
The best you can do is reordering them manually, possibly by taking advantage of multiple selection capability > mouse right click > send to top/bottom.
There's a reason the flag is called "accepted".
Also, there is no "solution" - if you want to rank a list, you have to use a rank.
It doesn't sound intuitive...if i filter by name and description I would expect a sorted list by name and in case of same name a second sort by description...
I think similar pattern should apply when sorting by rank ASC and by priority DESC,
First sort by rank and when the rank is the same sort by priority...therefore the first time i apply the rank filter all elements should have same rank(since i have not drag&drop any element yet) and a second sort should apply based on the next order by criteria...no?
I think there could be added feature to rank items around the same priority level only. For example lets have 3 items of high priority - currently Jira decides about the order while I sort with priority. Would be great if I could change the rank of the 3 items because I want the last one on the list to be done first.
To summarize I would have items ordered automatically by different priorities and ranked inside of each priority lvl. Of course ranking items between different priorities could be restricted.
I interpret the meaning of “rank” more broadly. The decision to assign an issue specific rank is typically based on some underlying business rule. For example, issue X ranks higher than Y because it has more customer value (or takes less time to implement). The execution of that decision in the default Jira implementation is manual – users arrange issues in the desired order using drag-and-drop, and the resulting ranking is stored in the rank system field.
I think the inconvenience that people mentioned arises in situations where the data that feeds into the ranking decision already exists in Jira, like Priority or Story Points. So, for example, ranking all issues in a backlog by Story Points in descending order requires moving issues up and down by hand, even if each has a story point value. Understandably, it can get frustrating.
One way to accomplish the above sort order is to add Priority (or Story Points) to the ‘order by’ clause of the board query. But as Nic says, since issues are no longer sorted by rank but by Priority directly, drag and drop stops working. It is logical if you think about it – drag-and-drop cannot change the priority or the story points of an issue.
Another way is to use a plugin that works with the rank field. The plugin will update the rank based on a rule that you define. You can have a look at Sort by any Field plugin our company (COGNITIFF) developed for this purpose, since we were facing the same issue.
Cool solution! Upvoted!
By the way, it would also be great if it supported a given calculation, like Value / Story Points, or something like that.
Promising app. Will test it soon!
I teach my product owners to use rank to determine the order in which they want things worked on, which is not always the same as priority.
Something may be a high priority ask, but may not be urgent. Something could be a low priority, but easy to deal with, and the person who knows how to do it best may be going on vacation next week, etc etc, and you put it at the top of the list so that they see it, even if the work itself is not a burning hot priority.
Priority in Jira is a terrific way to quickly see how important a ticket is, and if you want to, you can run queries to see how well your team handles A-level, B-level, etc... but in terms of actually managing your workflow, Rank determines where people will see the ticket in a list, and to me, that's what matters more (unless for some reason I'm filtering a list by priority, which I try to avoid doing, because it ignores rank).
I hope this makes sense to folks.
Ok so I just made a work around.
I created false sprints for each of my rankings.
Then I ran a filter with order by priority asc .. which then sorted my backlog quickly. Then selected all of the Must Have's right clicked and added them to the false sprint Must Have.
And then I did the same for Should Have, Could Have and Won't Have.
Then changed the backlog filter back to order by rank asc
So now the false sprints act like group by
That can't work because you couldn't then rank the issues.
There's no "group by" because JQL is a search for issues, it has nothing to say about what you report the list on.
I'm afraid that won't work - for ranking to work, you need to be able to rank across priorities. Ranking and prioritisation are not the same thing.
But it won't work, because ranking and prioritisation are not the same thing.
Yes, it has not changed, and it won't change either. The concept of a backlog implementation is that you put your issues in order, which you can't do with priority, you have to do it with a rank.
Thanks, can you help a bit on to use ranking? Is it just the manual order that you put your self in the dashboard backlog, when I add the field it look more like a code than a usable thing for user.
Yes, it's the order you put things in on the backlog. The field it is in is not really human readable, don't bother putting it on screens.