Closing sprint and issues move?

Do issues that aren't completed in one sprint automatically move to the next?  In my testing, that's not what appeared to happen, but that's what looks like is happening right now.


4 answers

They should move to the next open sprint, yes. This is taken from the documentation:

Other actions that occur at the end of a Sprint:

  • Your issues will move out of the Active sprints
  • Any issues not completed at the end of the sprint will be moved to the next planned sprint, as they did not meet the team's definition of "Done". If you do not have a next planned sprint, they will be returned to the backlog and will be visible in the Backlog of the board.
    • If you have parent issues that are not 'Done' but have sub-tasks that are all 'Done', the parent issues will still be moved to the next sprint/backlog. If these parent issues are part of another active sprint, the previously completed sub-tasks will still be 'Done'.  

That being said, we experienced a few instances when only a portion of incomplete issues were moved to the backlog instead. This seemed to occur only when there are large numbers of incomplete issues, and I could never provide clear steps to reproduce to Atlassian, so they haven't been able to confirm this.

If you can find clear steps to reproduce this, please report it to Atlassian.

What shell we do to move all incomplete issues to the top of backlog instead of bottom when we are closing sprint?

I am having the issue where the above is not happening. I installed a plugin that messed up workflows and now people that are running sprints that end early and are getting this error "Sprint cannot be completed as there are incomplete subtasks on the following issues:" How do I change it so that it starts putting unfinished issues back into backlog.

Hi Gregory,

In your active sprint, if you have closed stories with un closed subtasks, you won't be able to close the sprint. You have to first close the sub tasks and then try to close the sprint. 

Your plan sounds reasonable to me. As long as there are no planned sprint when you end an active sprint, incomplete issues will return directly at the top of the backlog.

As for FixVersion, I'm not sure what you mean. What makes you believe the FixVersion field might be removed? We've been using Agile 6.6.x for a while now, and that doesn't interfere with that field, which is not specific to Agile and continues to be used in JIRA.

In JQL: fixVersion is not EMPTY is still a valid check.

So we have to use an external approach to build our sprints and then I have to juggle JIRA issues to match the external approach, because JIRA is lacking a number of features that we need to help determine our ranking.

Then I have a series of scripts that use the RESTful calls to make adjustments.  Essentially, I

a) Create a new sprint

b) Update the sprint with appropriate name, start and end date

c) Rearrange the ranking of all issues, regardless of sprint status and add issues to the new sprint (this moves unfinished items from the current sprint to the new one, but ranks them where the stakeholders want them - sometimes they won't make the next sprint for any of a variety of reasons.)

d) Close the old sprint

e) Start the new sprint.

I'm wondering if, for some reason, items that aren't being ranked are being carried over when the close/open happens?  I've had issues just magically appear in my new sprint that should not be there, but were in a previous sprint.

Okay, I need them not to be; each sprint needs to be completely independent of it's predecessors.  As a result, here's what I think I need to do:

Complete/close the active sprint.

Create a new sprint.

Update the sprint...

Rearrange the ranking of all issues and add them to the new sprint.

Start the new sprint.

Sound reasonable?  I know that some places have this automatic carryover of items from one sprint to the next, but we're not one of those organizations.

In the same vein, is the FixVersion field going away with the new Agile release that blows away classic boards?  We use it to track the sprint/iteration where a fix was actually created (as opposed to tested / approved) - which is problematic with this whole sprint thing.  If FixVersion is staying where it is, then that addresses some of our longer-term concerns.

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

261 views 0 12
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot