How to align Story order in Next-Gen-projects between Backlog and Board

Tom Baake

Current situation

I have a Next-Gen software project in Jira cloud, with roughtly 100 Stories in a dozen Epics. We have prioritized them on the Backlog in Jira (upper = most important) and also create Sprints on the Backlog using the same prioritization method.

Once I start a Sprint, the team uses the Board where they assign and drag & drop tasks from Todo --> In progress --> Done. Pretty straightforward.

However, the order of the tickets on the Board does not match the order on the Backlog, thus the team needs to spend additional time comparing the board with the Backlog, which is inefficient. Also: issues without subtasks are grouped at the bottom swimlane.

 

Left screenshot: Board order. Right screenshot: Backlog order (same sprint).

   

Expected situation

1. (Most important:) I want the order of the tickets to be aligned between the two different view.

2. I want the order to change in both views when I make changes in one of them, to prevent misalignment.

3. I want to see the subtasks on the Board (therefor, I set the "Group by" option to "Subtask".

 

Any help is greatly appreciated. Thanks in advance!

Andy Heinzer

Hi Tom,

I understand the backlog and the board for a next-gen project appear to order issues differently.  However I think this is a matter of perception. 

The issues actually are still in the same rank (not order) in both views.  The difference here is that the backlog doesn't separate issues into their different possible statuses (all statuses are lumped together there), AND that the board view has additional group by options (such as subtasks, assignee, epic).  This allows you to configure the board in such a way that I could see why you would believe the issue order does not align, but I assure you the ranking of the issue does.  You could see this more clearly for example in the board view if you temporarily change the group by to the none option. 

The board will still organize issues by status, which can still work against your desired view here, but I think this change can help to visual that the rankings are connected here.

When you change the rank in one view (you would do this by dragging and dropping the issue), the rank value that issue has will change, but what it changes to depends on the rank values of the surrounding issues.  This is because ranking in Jira Software is a relative operation.  Meaning the rank of an issue is dependent against the other issues it is ranked next to.  More details on this in Rank an issue, check out the Important things to note:

When you move an issue from the Scrum backlog to a sprint, and it's the first issue added to the sprint, the issue will retain its rank. If other issues have already been added to the sprint, the ranking of the issue will be relative to the ranking of the other issues in the sprint.

So for example in the board view moving an issue to the top of the "In Progress" or the "To Do" status list is not the same as say, moving an issue to the top of the backlog view.  For you see, the board having multiple statuses has no way to know which status highest issues is actual ranked above the others.  Whereas the backlog transcends status of the issues, hence ranking in the backlog is ideally where you would do most of the ranking as it doesn't factor in the current status of the issue when determining rank.  You can still make changes to rank in the board view, but just understand that when you change the rank of the issue there, it is only ranking that issue against the other issues in the same status and the same swimlane.  That is all the more it is expected to do in that view.

As for the desire to see subtasks on the board, I understand seeing subtasks on the board can currently only be done by using the group-by option.  There are a few existing feature requests such as JSWCLOUD-18064 - Ability to view sub-task issue types in next-gen boards and JSWCLOUD-18393 - Ability to expand Stories to see sub-tasks in the Backlog page which I think would be applicable to the way you want to use subtasks in next-gen projects.  If you find either of those requests useful, I would recommend voting on those in order to help our development team understand how users want our products to work.

I hope you find this answer helpful, but if not, please let me know.  I am interested to try to help.

Regards,

Andy