How to see numeric rank/order for an issue?

[Russell A. Miller]

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?

[Petter Gonçalves · Accepted solution]

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!

[J Khan]

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.

[David Hanson]

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.

[Nic Brough -Adaptavist-]

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.

[Anthony Rose]

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).

[Nic Brough -Adaptavist-]

Ok, please see the thread above - everything you've said there is covered above.

[Chris Hurney]

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...

[Anthony Rose]

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.

[bschmuhl]

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.

[Nic Brough -Adaptavist-]

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.

[Anthony Rose]

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.

[jonathan r]

I can't believe this issue is still being discussed since 2017 !...
For our sake, add the darn feature...  Clearly your customers are asking for it...

I don't want to bring up the board and count to find out where the issue sits in the ranking, especially, for example my backlog is 100's of pages deep...

I agree with all those asking for it (including me over a year ago).

[bschmuhl]

@Nic Brough -Adaptavist- I understand where you're coming from. Here's the use case to help you understand where I'm coming from as I may not be the only one with this need:

I have a report that includes data from Jira (epic issue status, along with total, estimated and resolved issues within the epic), along with other project data from manual entry and other data sources, to provide an executive summary of our development progress. The rank I'm pulling from Jira helps me to order the projects in the report to mirror the same order that they have in Jira. Although rank is fluid, it's not so fluid that this report becomes inaccurate throughout the week.

If we were a larger company and I were pulling a report of rank on issues that are in the busy section of a backlog, we'd see more inaccuracy. But I'm pulling epic issues as representative of larger projects.  Additionally, because I'm pulling just the active epics, I have all the context I need. I don't need the actual rank value, I just need the rank relative to the other active epics.

It's likely that I'll create an additional report that shows the "top of the backlog" issues that are "likely" to be worked on next. This and my existing report would satisfy numerous stakeholder inquiries that happen outside of Jira. As it isn't feasible to have all the stakeholders in Jira providing these reports outside of Jira—but with a snapshot of Jira data—is super helpful in communicating what we need to help people make good decisions outside of product development.

I'd be happy to provide more detail if you're curious, but rest assured that I have what I need, and hopefully now that the rank field has been identified, the risk of data fluidity, and the need for context as explained throughout this thread, these other folks do as well.

[Anthony Rose]

That's a great explanation. That is very similar to our need.
I'd like to add a different scenario though.
Users can create JIRA tickets for defects. The JIRAs get ranked by priority to fix, by the resolution team. Imagine a user needs a ticket fixed urgently. When they open the JIRA to check on its status, imagine they can see immediately that it has been prioritised and it is #3 in the queue. No problem. Now imagine instead the position is shown #50 in the queue. Is that helpful? Of course. They're going to initiate a dialogue. Why? Because with 49 other defects to resolve ahead of this one, it is unlikely to be completed in time. How would they do this without the position displayed? Open the backlog and page down, like prehistoric man looking for good flint stones, counting tickets until they see the JIRA ID they are looking for. If they don't count, they have to initiate the call by saying "My JIRA is, um, quite far down, I think." "How far down?" "Well, I paged down quite a bit..."
Or imagine a user just needs to check if one change is scheduled before another. They can open the 2 JIRAs and compare their positions: 71 vs 101. Easy. How would they do it without this position displayed? Open up the Backlog  and start paging down, carefully reading all the JIRA IDs until they see the last JIRA they are looking for, which could very well be at the bottom of the list.
And all you need to solve this is to do that counting for the user. If reading the entire board is too much work, create an internal Position table of JIRA IDs and ranks, sorted by rank every time a rank changes or a JIRA is added or deleted to the board. When a user opens a JIRA, you also read the board's Position table to find its ID at position n. This is cheaper than the user reading all the JIRA titles manually with the page down key.

[KevinH]

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.

[Paul Benati]

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.

[Nic Brough -Adaptavist-]

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.

[Matt]

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?

[David Hanson]

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.

[Nic Brough -Adaptavist-]

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.

[MattS]

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.

[Nic Brough -Adaptavist-]

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.

[Russell A. Miller]

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 B) 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.

[Nic Brough -Adaptavist-]

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

[MattS]

I do see that it's hard to use a visual indicator when you have many issues to rank.

I think the way Atlassian intends the backlog to be used is that you keep it short (not easy) or rank the ones you care about to the top of the backlog and ignore the others for now. They might reason that you only care about some small number of Stories

[Donny Kirkland]

I would like to filter the backlog and see the number of the item ex 3/134 

[Nic Brough -Adaptavist-]

That has been discussed above

[Shanta Nathwani]

I agree that this would be a helpful tool to have, or at least the ability when viewing a single issue, to view its position in the current backlog or sprint. Working as a client representative, when I'm viewing an issue for the first time, I have to open a new tab and search for the issue in the backlog. Why not just take me there with a single click, if it needs to be a visual one. I can see in the notes that an issue has been "Ranked Higher", so there is a "rank" field somewhere. 

[Shanta Nathwani]

And I just figured out how to see it on the current board. Sorry gang! Glad there is the ability to view it on the current board, including the backlog. 

[jonathan r]

how were you able to display Rank ?

did you make it a displayable field in the issue ?

[Nic Brough -Adaptavist-]

You can add the rank field to displays, but it won't mean much to a human.

[Shanta Nathwani]

@jonathan r  On the right side of the issue, use the three dots to access the full menu and click "Agile Board". That will take you to the issue on the board itself.

[jonathan r]

@Shanta Nathwani How does going to the agile board itself help me display the ranking in the issue ?

[Nic Brough -Adaptavist-]

Because a board shows the issues in their ranked order.

[Shanta Nathwani]

@jonathan r Not well. Still no solution

@Nic Brough -Adaptavist- I want to be able to look at a ticket and know where it ranks. Looking at the board itself, I'd have to sit there and count the position. This really seems like a no-brainer.

[Nic Brough -Adaptavist-]

The rank of an issue is an indicator of where the issue is in an ordered list.  On its own, out of context, it isn't useful. For example, if I were to tell you the rank of an issue is 85, you wouldn't know how I am numbering or ordering the list, what issues are more or less important to me than this one, how many issues are above or below, and you wouldn't know how long the list is. 

You would need to look at the list to see what the data means in context, which you can do in the backlog and board.

[Pablo Osorio da Silva]

Its difficult to understand why many are defending JIRA on having rank value hided, claiming there is no need to have it. 

Context is something that you probably you know already (is it on backlog? on sprint?), but as you have to order your backlog, and you have a list of more then 100 issues there... it really is difficult to navigate, scroll, and be aware where you are in the list. Having a value, would visually help while browsing the backlog, as would help while opening details of a issue.

If you don't find it value, is just the same with all so many other fields that some use and other don't, but please give us the option to use it!

[Nic Brough -Adaptavist-]

The actual rank is usually hidden, but you can put it in view if you want.  It's pretty meaningless to people though, as it's not a simple number.

I wouldn't argue with putting a number next to the backlog items either, but they obviously wouldn't be a rank and would not go on to the issues themselves.

[Pablo Osorio da Silva]

Yeah, I saw video someone post on some thread, explaining the AAA lexorank. How do you say that I "can put it in view"? There is no option to add it to Card Layout.

[Nic Brough -Adaptavist-]

The card layouts don't support adding rank as a display field (because it's utterly useless in there.  It looks like a text field with no useful information and even if it were a number, it tells you nothing.  And it duplicates the information you have already from the positions of the cards on the board).  You can add the field to the Jira (Core) issue view if you really want to see it.

[Pablo Osorio da Silva]

It really makes me wonder why you (and others) state "no useful information", specially if we're talking not about lexorank but an xx or xx/yy value. It's the same as saying that the row number in Excel is useless. Row number or backlog order, is exactly the same, a visual guide of where you are in that list.

[Nic Brough -Adaptavist-]

The numbers you see in Excel are not a rank, they're a reference to the current line as determined by the current sort and layout. 

They change if you sort the rows differently, and hence they are completely determined by context (for excel, that's limited to the sort order)

They give me no useful information outside the context of that one sheet with its current sort settings.  Image we have a shared list somewhere that Excel can read.  You, I and my cat open that list on three different computers.  You sort it by "importance", I sort it by "assignee" and my cat sorts it by "likelihood of getting tuna".  We almost certainly have different excel row numbers for most or all lines.  That is not a rank, and it's not useful.  Row number is row number.  It's not a rank, it's not a visual guide of where you are because it's different for other people and it's not useful outside what you are currently doing (which is not what other people are doing).  I can't tell my cat to look at row 85, because she's got a different item on that line.

[Anthony Rose]

I think you're obfuscating the issue by bringing multiple rankings into play in order to show how meaningless rank is. Of course rank (x) from ranking A is useless in ranking B. But that's not relevant here. In the current topic we're discussing a single ranking in order of importance. I'm not sure why you brought multiple rankings into the conversation.

[Jonathon.Penberthy]

@Nic Your right I am not interested in the number, I thought I was too, but this is my actual use case.

"As a product owner I would like to decide on the priority of the issues whilst reading and understanding its details."

A suggested implementation might be that whilst I had the issue open I could see the title of the Issues ranked immediately above and below it with maybe a "move up" and "move down" button to help me set its place.

[Nic Brough -Adaptavist-]

That is exactly what a backlog view provides.

[Nic Brough -Adaptavist-]

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.

[MattS]

And keeping that working in JIRA Data Center would be tough!