Complete sprint and move incomplete tickets to future sprint, destroyed order in future sprint

[Ramona Wechsler]

Our backlog is structured into sprints, with all tickets carefully prioritized within each sprint. However, when we close the current sprint and move open issues to the next one, the prioritization in the upcoming sprint is completely disrupted.

Tickets that were already in progress in the previous sprint are mixed in randomly with the existing tickets in the new sprint. Additionally, the original order of the tickets already planned for the next sprint is lost, resulting in a disorganized and unclear prioritization.

[Trudy Claspill]

Hello @Ramona Wechsler 

Ordering of issues by Rank is global and relative between issues. It has nothing specifically to do with the sprint or status to which they are assigned.

When you look at the issues that were pre-assigned to the next sprint, have then remained in the same order overall, with respect to each other? Disregard that the issues from the current sprint may be interspersed among them.

When you look at the issues that were moved into the next sprint from the current sprint, have those issues remained in the same order overall, with respect to each other? Disregard that the issues in the next sprint may be interspersed among them.

So, let us say that in your current sprint you have issues in this order:

1
2
3

And in the next sprint you have issues in this order:

4
5
6

When you close the current sprint you could end up with something like this:

1
4
2
3
5
6

1, 2, and 3 are still respecting their previous order. 4, 5, and 6 are still respecting their previous order.

Prior to closing a sprint you may want to try running a filter to search for the include issues in it and the incomplete issues you have assigned to the next sprint, and ordering that filter by Rank; i.e

type in standardWorkTypes() and statusCategory != Done and sprint in (<current sprint>,<next sprint>) order by Rank

That will show you how the issues are ranked globally with respect to each other, regardless of sprint associations and statuses. If you then Complete the current sprint and move the issues to the specified next sprint you should see that order maintained.

Since the Rank is global and relative, if you reordered issues in the current sprint that could change their relative rank compared to issues in other sprints also.

[Varsha Joshi]

Hi @Ramona Wechsler 

I had the similar challenge, so I started addressing all unresolved issues either to backlog or future sprints that way it keeps the next sprints unaffected.

[Bill Sheboy]

Hi @Ramona Wechsler -- Welcome to the Atlassian Community!

Short answer: if you are on a paid license, I recommend working with your Jira Site Admin to submit a ticket to Atlassian Support to take a look: https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit the community.

I did not find any documented behavior or open defects in the public backlog for this symptom.  And, I hypothesize the filter they use internally to select and move the work items to the next sprint does not enforce any ordering.

During the sprint, when a team member moves a work item from one column / status to another on the board, that can change the Rank as a result of the drag-and-drop.  Only when the status is changed directly using an edit with the status dropdown field is the Rank preserved.

And so...I wonder if you are describing what you see in the backlog for the next sprint before it has started where the Rank has changed due to earlier drag-and-drop operations, or from the move to the next sprint.

Kind regards,
Bill