Inconsistent behavior when Sprint field is used to move a ticket from Backlog to a Sprint

[Saeed]

Can anyone please share a document that explains logic for the following two scenarios?

When using the Sprint field (instead of drag/drop) to add a ticket to a sprint, location of the ticket in the Backlog affects the placement (rank) of the ticket in the sprint. Here are the two scenarios:

• Scenario 1:
  - TKT-123 is the last ticket in the Backlog
  - In TKT-123, set the sprint to Sprint 1
  - Jira places the ticket at the bottom of the Sprint 1
• Scenario 2:
  - TKT-123 is second to last or higher in the Backlog
  - In TKT-123, set the sprint to Sprint 1
  - Jira places the ticket at the top of the Sprint 1

If there is a way (configuration) to always place the ticket at the bottom, that can resolve my issue.

Thank you.

[Trudy Claspill · Accepted solution]

Hello @Saeed Vand 

Welcome to the Atlassian community.

The Rank of an issue is determined globally, and is not impacted by it being either in a backlog or in a sprint.

When you drag and drop an issue from the Backlog into a Sprint you are simultaneously changing its Rank because you are dropping it into a specific position in the Sprint. Dragging and dropping issues is the only way to change their Rank.

When you edit the Sprint field you are adding the issue to the sprint without changing its global ranking compared to other issues.

It is possible that if you saw all the issues in a single list showing their true rank, then the issue at the very bottom of the backlog would truly be at the bottom of all the issues, while an issue not at the bottom of the backlog is actually ranked higher than some issues that are in sprints.

If you want to see the true Rank of all the issues in your Scrum board, disregarding their presence in a sprint or in the backlog, really the only way to do that is to create a Kanban board that uses the same filter and then map all Statuses to one column. That will put all the issues into one column in the Kanban board and you would then be able to see their true rank without regard for being in a sprint or in the backlog.

I have not spent time actually testing out the scenario you described. I'm answering based only on my understanding of how Ranking works. It is entirely possible that what you are seeing is not actually adhering to the true rank of the issues.

Here are a few articles that talk about Ranking of issues:

https://www.jirastrategy.com/questions/how-does-jira-issue-ranking-work

https://tmcalm.nl/blog/lexorank-jira-ranking-system-explained/

Also in this KB

https://support.atlassian.com/jira-software-cloud/docs/rank-an-issue/

...there is this 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.

  In other words: Issues are only re-ranked (upon being moved) when there are other issues to compare them with in the same sprint (or backlog) where they've been moved to. The idea is that rank is managed within a sprint (or backlog) itself, not across sprints.

[Saeed]

Thank you Trudy and apologies for not responding earlier. I understand the ranking is global. However, I assumed that the tickets in the Backlog are ranked lower than tickets in the sprints above it. I used Advanced Issue Search and I see that what is displayed in the Backlog board is not the true ranking.

As an FYI, the issue this is causing is that we use a Sprint for the quarterly planning process and we want the newer proposals to be placed at the bottom for discussion. Drag/drop works. However, most PMs use the Sprint field. They create the tickets in the backlog and when they are ready, they add it to the quarter’s sprint. Depending on the ticket's global ranking, tickets are placed in various places in the sprint and this is affecting our planning. We have to keep track of what has already been discussed and what is new and manually move them to the bottom of the sprint prior to our review/approval/trade off meetings.

If there was an option to place the ticket at the bottom of the sprint, this would resolve the issue we are facing.