Currently my rank field is populated with odd combinations of alpha and numeric characters. For example, the top five items in a backlog (in descending order) are:
I also have to agree with Janet and Mandy - the very simple real world use of a numeric 1-2-3-4 would GREATLY help me in communicating the backlog to people. Please update me when you add back the feature to have a common language rank. It is the number 0|r90tqx: feature for you guys to add.
Could you please explain why Lexorank is better? I've never found 1, 2, 3 to be unreliable or fail to work.
My team is doing software development, and our backlog would normally be 1, 2, 3,... We don't need other functionality, and would like to be able to tell what a column of numbers means. This just looks like gibberish:
When I searched for information on LexoRank, I didn't find an explanation, but I did find a bug: https://jira.atlassian.com/browse/GHS-11358
Well, the major improvement in JIRA Agile which came with the lexorank is the possibility to work in a clustered and database agnostic environment. You can found further information about this in https://extranet.atlassian.com/display/GHDEV/LexoRank+%3A+A+Cluster-Safe+Ranking+System You may also be interested in the discussion in https://jira.atlassian.com/browse/GHS-10748
I'd have to agree with Janet. When looking at an issue in any detail screen, you have no way of knowing where the issue falls in priority on the backlog. I don't want to have to keep switching back to the backlog view to know where the item has been ranked. I'm sure the algorithm is fine, but I need an equivalent numeric value for when items are in detail screens to provide context that is human understandable. Thank you.
Not to pile on but my company is having a very similar issue and i believe Janet is exactly correct. I am well aware of the advantages of the Lexorank algorithm but most of those are behind the scenes; there must be a front facing value that makes sense to humans. There are a number of reasons why users would need to see the rank value outside of the Agile Board Planning view. They are displaying in the correct order, it cannot be that difficult to assign an ascending value starting at the first entry. Please help!
The newer version of JIRA Agile does not rank issues using a number, but a lexical value, using the lexorank algorithm. So, if you are facing this issue after upgrade JIRA Agile, I do not think you will be able to use numerical values again to rank your issues.
The Lexorank algorithm has a lot of advantages when compared with the numerical rank, as being more reliable and work in data-center enviroment.
Teilor, your comments above have links that give me a 404:
Do I need another login?
This ticket does appear to be a duplicate of https://jira.atlassian.com/browse/GHS-10748
Sorry Janet, I didn't notice the access to that document was restricted; you will not be able to view it. If the change from the numerical rank to lexorank cause a negative impact in your JIRA instance I would recommend to you to create a Suggestion to our developers in https://jira.atlassian.com, with details about your user case. We also have a Support channel in support.atlassian.com
There is no issue.
Lexorank is better than numbers for ranking, both for coding in Cloud and Server, and it's pretty much mandatory for data-centre. There's a good reason the original number system was dumped in favour of it, and numbers will never be re-implemented (they weren't great before as they couldn't be 1, 2, 3 in any system that needs to perform)
...and thank u for ur comment.
Plz give me 1(one) reason why for humans, a visible field with this content 0|i0005g: should be better than a number. Fair enough, if used in the background for coding in Cloud and Server...
...but users..? ;-)
Are u with Atlassian? Are u in the Team responsible for this change?
No, you're right in that it's useless for us.
There's a small oversight on the part of Atlassian here (I'm not an Atlassian) - they actually allow you to see the rank on screen. Sometimes, an admin might find it useful for debugging, but if was an Atlassian UI person, I'd have hidden it as much as possible because its of no use to humans. Ideally, it should be replaced with a display of previous and next issue in the list.
And there we have it. Yet another example of a tool that is built to some notion of technical best practice rather than serving the needs of its users.
I'm convinced that the Atlassian product management team don't ever test with users. They just make decisions internally then wait for the feedback... which they generally ignore as far as I can see.
It's not about technical best practice, it's about numbers simply not working. Imagine you used a simple 1, 2, 3. Now you have a system with 100,000 issues in it, and you rank something new as 2. You now have to edit 999,998 existing issues with new numbers.
The old system they had before lexorank did it by leaving gaps, so issues were ranked at 10000, 10010, 10020 etc, so you could now insert 10005 to get something to be ranked at 2, and although that gives you a bit of space to renumber issues, it wasn't enough, and sprint planning sessions would cause massive load as it got thrown into cycles of mass renumbering while trying to make more space. And people looking at the ranking number started complaining that they weren't sequential. So a new system was needed.
The important thing is that one can still sort by the Rank column in Excel, and it maintains the stack rank order seen in the Backlog or Kanban boards.
I recently wanted to analyze whether our team had recency bias, i.e. whether more recent Jira issues would tend to be ranked more highly. Calculating issue age and then sorting by Rank allowed to graph in Excel and calculate trends (R-squared measure) just fine. So Rank is no longer human readable as regular numbers would be, but you can still sort an issue list and maintain the rank order.
BTW: The answer to the question of recency bias was "No" in short-term (Status = Selected For Development) but "Yes" in mid-term (Status = Backlog).
@Tom Hammarberg I have a solution for you. Because the Rank field is sortable as text, you can derive the numeric rank using an Excel formula by counting the number of rows in the table where the Ranking string is less than the Ranking string in the current row.
- export to Excel (All Fields)
- in an empty column set up the following formula:
where the $CY is an absolute reference to the column where the Lexorank values are (in my instance it's titled "Custom field (Rank)".
In R1C1 notation the formula is:
where the Lexorank is in column 103.
That formula will return 0 for the highest ranked issue, 1 for the second, etc.
Note it only returns the relative rank for the issues within the scope of the Excel table, obviously not the issue's rank across the whole Jira instance.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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!
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