Force Rank Backlog Priority

Question

We have had a lot of issues with the internal JIRA ranking system (as it seems a lot of users have), and it appears the only solution to maintaining the backlog prioritization and rank in a more uniform way is to add a custom field and sort off that field for the backlog view.

For example, create a numeric custom field named "Backlog Priority" and filter the backlog on that field in ascending order.  Seems straight-forward.

However, I read on another thread that if we do that we lose 2 pieces of functionality:

1) drag and drop - this is good! that's what's causing all the backlog prioritization issues currently.

2) you can't start a new sprint unless the backlog is filtered on the Jira Rank logic. - is this true?  that seems like a pretty monumental miss?

Last question: Is there anything else that I'm missing by introducing our own custom field to better maintain backlog priority?  Are there any other downstream issues this creates?

Nic Brough -Adaptavist- · Answer

>I follow your logic, but there are plenty of ways around this.

Well, there are a few, but the best (I've seen) so far is to use a field that supports proper ranking

> Using TFS as an example ... support decimals ... but it functionally works. ... Greenhopper

This is almost what Greenhopper used to do, without the decimals - it allocated new numbers in 10s, then filled in the gaps when things moved (i.e. instead of 6 and 7, then 6.1, 6.2 etc, it had 60 and 70, then 61 and 62)

This failed, and failed hard at scale.  This is the entire reason a proper ranking field was built to replace it!

>the Rank field cannot be exposed and modified is a huge hindrance.
I agree with the exposure point, it would be nice to have something built-in that says things like "the issue above/below this on the list is", and then some way of seeing how important it is overall.

Modification is a bit more difficult - it's pretty useless saying "this issue is important", as what you really want is the context.  Not just "this is more or less important than a load of other things", but also "more or less important in a sub-set (i.e. a backlog, not the entire list)"

In both cases though, it is about relativity.  A value of X for an ordered list is useless on its own, what you need is the context for it.  Telling me an item has value 7 is not useful, even when I know that items with lower values are more important in the list, there could be 2 items with lower ids, or hundreds of thousands.  And I'm going to want to know what they are to see if I agree that item 6 really is more important!

>We've found that every time a new issue is added to the backlog, it somehow supersedes an existing issue.  
I'd like to see "insert" configurable somehow.  Not sure I know how, maybe "new items are added to the bottom of the list or top of the backlog (but still below the sprints so we don't mess up any planning)" config item for the board admin, with some function that asks the user "top middle or bottom of the backlog, or relative to a specific existing issue, or some other rule"

>Using an invisible field, while configurable, is not a great solution for complex backlogs.
It's functionally better than using a visible one without context, as above.

>If anyone else has other ideas on a better solution, I'd love to hear!
Totally agree.  The problem I've seen is that when people start to grasp the problems above and why ranking works and "settable non contextual" does not, we all struggle to come up with something better than ranking as it is.  I've scribbled improvements above, not a better fix.  I'd love a better system.

Lee Eubanks · Answer

I follow your logic, but there are plenty of ways around this.  Using TFS as an example (albeit a TERRIBLE solution for backlog maintenance), it would allow you to support decimals, i.e. if you have four items with a backlog of 6, you'd just increment them to 6.1, 6.2, etc.  This is not ideal, but it functionally works.

I honestly do not recall when I used Greenhopper years ago in a previous job ever having this issue.

I do not disagree with what you're saying in principle, but the fact the Rank field cannot be exposed and modified is a huge hindrance.  We've found that every time a new issue is added to the backlog, it somehow supersedes an existing issue.  Using an invisible field, while configurable, is not a great solution for complex backlogs.  There are too many stakeholders to expect product owners to monitor EVERY change to the backlog in real-time.

Reading the threads on this issue, it definitely seems I'm not alone in this sentiment that there should be a more straight-forward process to maintaining backlog priority, but I really do appreciate the response.

If anyone else has other ideas on a better solution, I'd love to hear!

Nic Brough -Adaptavist- · Answer

This happens a lot because people do not think through ranking properly.

A human can take a list of things and put them in order and handle it intuitively, but you need to have rules about what that ordering is, and you have to agree them with other people and explain them to computers otherwise you can't understand it.

So, when you are ranking a list, you and I look at it and arrange things, say, top-to-bottom, instinctively thinking "top of the list = most important and hence needs doing first".  Behind that, there is an underlying mathematical fact - they are in an order, each item having a relatively abstract rule like "1st, 2nd, 3rd, 4th", or "I am lower than that lot, but higher than another lot".

That is what the ranking is.  And the rank field uses a lexorank thing that does the higher/lower.

Now, replace that scheme with the first one - simple numbers.  You can put any number in, but let's say our users are good and just put in 1, 2, 3, 4 and 5.  What happens when issue 6 comes in and you want to rank it in place 3?  You can't say "3" because that does not re-rank items lower, and it can't be on the same line as 3 because there's already one there.  You can only add a 6 to the possible list and then shove 4 and 5 down.  To re-use your example of "backlog priority", you say "filter on it", but then you still have not ordered it.  How do you order three items that have the same backlog priority?  Answer - you can't, because you need a ranking field to do it.

The reason you cannot rank on a number, or priority, or string or anything else is that they are not capable of being ranked.  They allow duplicates and don't shuffle the whole of the rest of the list when they're changed.  You need a field that handles ranking.

On point 2, the issues in a sprint is defined as the "set of highest ranked issues we have drawn a line under".  If you've not got a ranked list, you can't define it, and hence can't start one.

(Note - I strongly support the idea that I could *sort* a backlog, or sub-set of a backlog based on other fields, re-ranking them all to get me started, but then I'd still need to have the rank field for me to re-order them later)