I want transparency around the order of an issue in the Product Backlog.
If the Product Backlog contains 134 issues, I'd like to know where a particular issue sits in that order 10/134? 27/134? 120/134?
How do I accomplish this?
Hello everyone,
Thank you for all the insights and information provided about this topic.
Today, I'm afraid we don't have a way to configure a numeric rank that would display the position of an issue in a specific board, like 10/134, 27/134, 120/134, etc. Instead, we use the default Rank field which stores the position of the issue rank across its board/sprint with an alphanumerical logic, as explained in the documentation below:
https://support.atlassian.com/jira-software-cloud/docs/rank-an-issue/
https://support.atlassian.com/jira-software-cloud/docs/enable-ranking/
We completely understand the value to have a field that provides a human-readable numeric rank and that's why we created the following feature request to track its impact on our customers:
Display human-readable the rank on the card in the backlog
Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), that feature request didn’t make it to the roadmap and we decide to not implement it.
If you disagree with the decision made and think this feature should be implemented, please provide us with your feedback in the feature request as a comment so our developers can consider its implementation again in the future.
Thanks!
I can't think of a way to do this in JIRA itself, I think you'd need an add-on to provide some javascript that would read the length of the current list and inject numbers into the display.
And keeping that working in JIRA Data Center would be tough!
Actually, the question is what business advantage does having that number provide? The issues already appear in the tool in the ranked order.
Atlassian have chosen not to expose a numeric rank. In fact they got rid of it when they changed JIRA Agile to support Data Center around 6.4
As Nic says, some javascript that looks at the currently available list of issues in the backlog and adds a number to each one is one approach.
Yes, good point. I can't say that I can think of much use for the number, especially it would be specific to a board at the time of running the backlog view. As a reference, it's useless, as "#86/134 on board X" could be a different issue 10 seconds later, as could the count. Whilst on the board in the backlog, well, I know they're in order anyway.
It is useful for Product planning to be able to understand a Product Backlog Item's order in the backlog. Relying on only a visual indicator is insufficient when A) the list is longer than a single page or you wish to know the position of multiple items or C) if you wish to record the position to communicate to someone else.
If you want to compare 4 items and their position, knowing this:
Item 1: 23/134
Item 2: 18/134
Item 4: 65/134
Item 4: 83/134
is very, very helpful.
But they'll be in that order in the backlog, so I can see that.
There's no point in recording the position for someone else, as per my previous comment
I find the responses to repeated requests for a simple ranked number value frustrating. “I know you want it, but you don’t need it.” For me this is a deal breaker. Visualizing work is a basic Kanban principle. When looking at a single story, I want to know this is rank “17/134” without having to navigate to a backlog view.
It's not a case of not needing it. You do need to see the order.
But you'll have to do it with a relative script that is for display only, and will change by context (apparently randomly at first glance)
"Simple" numeric ranking at a global level increases the work any re-ranking work exponentially by the number of issues you have, so it really can't be done in real life.
Can you suggest the “relative script” or marketplace plugin that we could use “for display only”? That would be sufficient for our team’s needs. Our team cares less about global ranking. We are only concerned with the rank of our “134” item backlog.
I have not seen any js hack for it since Jira 5, and that won't work now. I'm not aware of any plugins that do it either.
A bit late to the discussion here:
Acknowledging the necessity of 'context' to understand what 85/134 would mean, a stripped down manipulable view of the Rank list, without Sprints, would be helpful to me. I have a constant intake of 50+ NEW stories per week for a large implementation with issues that could rise to high priority ranking; however, am also using a Portfolio view requiring loading into Sprints for a longer term view of MVP delivery timing. I don't have the luxury of simply organizing into a Sprint ahead with the rest of the issues in the 'backlog' (this negates the JIRA Portfolio view. Most large corp management chains require delivery visibility which requires Sprint alignment for Portfolio - i.e. NOT Agile, 'work a year ahead' for budgeting estimates).
A clean Rank view would help me re-prioritize rankings in light of additions/changes and allow realignment to Sprints based on capacity estimates in Portfolio.
Looking for community feedback on 1) how to accomplish both short and long-term views while re-ranking a constant influx of new issues and 2) see Rankings easily without ripping items out of Sprints and loading back in to Sprints for Portfolio view.
Also, ability to easily convey a numerically ranked list (yes, snapshot in time) to an executive team, that will not navigate to a JIRA board, would be an additional win.
I agree whole heartedly with the sentiments that seeing a single JIRA issue's numeric rank, out of context, has no value.
However, I would argue that having a human-readable numeric rank might have some administrative value. Let me be clear...I am an agile practitioner, and the last thing I'd ever want to do is add more administrative overhead, in some tool, for a team.
But, what if I had just created an issue in JIRA, and prioritized such that it's stack rank is 35. Then, what if, a predecessor emerged, I authored the new dependency in the tool, and was able enter "34" in some stack-ranked field, without having to go back to the larger, global backlog and drag that new issue to it's proper location (although, I'll admit this may not be an issue if creating a predecessor 'automatically' put the new issue in the appropriate position in the backlog. But I could see other administrative advantages to having this functionality as well.
I guess the question I'd have for Atlassian is, if enough people are asking for it, why NOT put this functionality in? What potential pitfalls, dysfunctions, or anti-patterns might occur from having this functionality in place?
Looking forward to the replies...
Just to add to this - would be something quite helpful for me too. We have a number of different dashboards and boards that give different views of the same information (e.g. a status view for scrum teams and a status view for product, and a status view for programme). Trying to get some JIRA-phobic people to use the tool is proving problematic because they can't see the priority / rank very clearly.
I wonder if there is a way to write a scripted field / calculated field that:
a.) returns the total number of issues in a saved filter (e.g. 103 issues)
b.) returns the key value of all issues within the same saved filter, along with their rank value
c.) uses the rank value and the returned tickets to identify the position of the ticket within the filter (e.g. position 39)
d.) formats the value from a (103) and from c (39) into something readable (e.g. 39/103 or just 39)
That way rather than seeing my ranked ticket as value 103780 I would see it as "39 / 103" or just "39".
Beyond my scripting capabilities at the moment, but seems like something that might reasonably be possible?
My org needs to maintain order of the cards across and within each column of a kanban board.
I have a need put a card on our kanban board back to the column it came from if that column's definition of done is not completed. As a simple example, a kanban board has three columns: To do, Doing, and Done. And there's a business rule that requires that a custom field, Peer Reviewed {Yes, No}, is set to Yes for the card to move into the Done column.
Leveraging a tool like Automation for Jira I can move the card back to where it transition from, but I can't put the card back into the order within that column. This order is important as a kanban board's priority is denoted by top right is the highest priority followed downward within that column, then to the right-most column minus one top to bottom, etc.
My org needs to maintain order of the cards across and within each column of a kanban board and that's not possible if the rank order field isn't exposed.
Seeing a rank field is not going to help you with that. You would need to record the issues that are above and below it at the time it moves, and then work out how to re-rank the issues when you move the issue back. You also need to hope that the two issues are not re-ranked in a way that makes it impossible to put the old card back in the right place.
I do not have a solution for you but having read the answers so far I have to disagree with all the people suggesting that an understandable visible rank is not needed.
Is it useful, to know an item is ranked 1 or 83 or 149 out of 150? Of course it is. The context is a single count: the number of items on the board. 1 means it couldn't be escalated more, 149 out of 150 means it's at the back of the queue, 83 out of 150 means it's not a high priority. You don't have to be viewing all the items above it at the time. Position is useful information in itself.
Is it slow or clumsy, to have to page down the ranked list until you find an item being asked about, and to have to give an executive a fuzzy answer, well, I paged down 3 times before I found it, so it's around a third-of-the-way-down, with about 70 items ahead of it. Or more simply, it's quite a way down the list. Or to have to count items... Embarrassingly clumsy.
Is it difficult or time-consuming internally, to show a positional rank number on request? It means you have to read the existing rank value of every single item in the board query, sort it (which doesn't take long when you view a board, so is definitely feasible) and assign a temporary position number out of total count to each item. Excel does it in the blink of an eye with tens of thousands of entries. No, it's not difficult.
I'm also a bit concerned that people can rank so easily without an undo option or any record of previous ranking. What if an item is accidentally dragged? Or someone re-arranges the board for any reason? I would have a versioned ranking order per board which is external to the items, and each time an item is added, deleted or rank is changed, create a new version of the ranking order.For example, current items are A,B,C,...Z.Current version of ranking order is A=83,B=1,C=149,....,Y=101,Z=19. Total count 26.Someone adds item X and drags it just above item A,New version of ranking order is now A=84,B=1,C=150,...,X=83,Y=102,Z=19. Total count 27.
In this way there would only be one update when a rank is changed, you could always have a visible positional rank, and a person could view the previous rankings of an item, or even request to re-apply old rankings (with options to handle item-exists discrepancies, of course).
Came here looking for this solution - Would like to use an analogy to maybe more clearly explain a use case.
When you are on hold on the phone, and it says "you are caller number 15" - that tells me there are 14 other callers AHEAD of me that need to have their issue looked at, address and resolved before it will be my turn.
I think "rank" is the wrong term since we have priority and impact to help with that. but more, based on those ranking metrics or set sprints would cause a sort order of a list of issues within a project (within sprints and backlog), out of all the outstanding (not "done") issues and return how many of them are queued to be worked on before this particular issue.
There is huge value there because the reporter is often wondering - "why is my issue not being worked on?" aka 'why am I still on hold' - being able to see, oh this issue is 85/135 would tell me that there are 84 PENDING issues ahead of mine and that if I were to add another one, there are already 135 in the backlog. It would save mountains of dialog between stakeholders and engineers to have this metric clearly visible within the issue. Because let us be honest, our stakeholders are too lazy/inexperienced to click through to find a kanban/scrum board and accurately read it to understand where their issue lies in the large scheme of things.
At my company somebody created a Python extract of JIRAs to a CSV file, including Rank which is customfield_14240 here.Once in the CSV, we use Excel to sort by Rank then replace the Rank value with ROW number.I note there is been dead silence to both my previous comments. I can't imagine what the reason is.
Thanks @Anthony Rose for actually providing a field! I'm trying that now and I hope that it works, given others have said that Jira is no longer exposing the rank.
It didn't work. But I found this post that identified the format of the rank (not simply numeric). https://community.atlassian.com/t5/Jira-questions/How-to-get-the-rank-with-Jira-API/qaq-p/583700
Looking for a value with that format gave me this field as the Jira rank: customfield_10019 It appears to be sortable alphanumerically.
For those wondering why I need the rank: when pulling out issues via the API to render reports outside of Jira, knowing the rank helps me to order epics and backlogs in the same way that Jira does.
This still has the context problem described above, and adds the problem that your rank is obsolete (and hence often wrong) as soon as you've downloaded it.
Nic You've still not grasped the basic concept that in a measure like 17/34, both numbers ARE the context - despite numerous explanations to you.You've still not grasped the previously given solution that ranking can be stored external to items and so a measure like 17/34 can be updated with just ONE update to a string of 34 references.You seem to be set on proving, against many customers' opinions, how useless a ranked extract is, by pointing out that it is instantly obsolete - yet it hasn't occurred to you that every single management report ever made was in the same position.I don't know what the cause of this determinedly irrational approach is - it surely couldn't be stubbornness, foolishness or direction from above to obfuscate the issue - but at the moment you're making Atlassian look, at best, incompetent.For the sake of Atlassian, and customers, I recommend that you get some senior management involved.
Ok, please see the thread above - everything you've said there is covered above.
It looks like you're new here. Sign in or register to get started.
