Closing sprint and issues move?

[Lee Correll]

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.

[Nicolas Bourdages]

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?

[Gregory Hicks]

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.

[Krishna]

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. 

[Michelle Sullivan]

I have closed my EDP Sprint 1 and MDM Sprint 1 after I started Sprint 2(s) for each.  All issues complete/Done and open moved to Sprint 3s.  How do I clean up Sprint 3?

[Nicolas Bourdages]

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.

[Sonia PASCAL]

Hi i would like to move some tasks to a closed sprint (by mistake it stays in the next sprint) . is it possible ?

[Jack Brickey]

If you mark the issue as done and set the sprint to the closed sprint does it achieve your goal. 

[Sonia PASCAL]

Thank you for your reply. In fact it is a story with 30 sub-tacks .

20 were finished during the Sprint 3

10 have to done during the Sprint 4

As I couldn't finish the sprint 3 as some sub-tasks were not fisnished, I moved the story in the Sprint 4. But it pollute our report of the Sprint 4. So I create a new story in the Sprint 4 moved the sub-tasks not finished in it. And I would like to move again the old story with the finished sub-tasks in the previous Sprint . But it is closed ans it is no more in the list !

How can i move a story to a finished sprint ?

[Jack Brickey]

Edit the story directly in the View issue screen. Search for it and edit. If the sprint field there are some tricks to do so but won’t go there unless we have to. 

[Sonia PASCAL]

Sorry Jack but i didn't understand your answer.

How can I move a story to a sprint which is finshed ? Or is it possible to open a sprint finished in order to move in it a story and close it after ?

How can I see a previous sprint ?

[Jack Brickey]

this is a bit tricky and a bit of a hack so I don't generally recommend it but...

Acquire the SprintID (not the name):

1. using Firefox
2. display the View issue screen
3. click on the Sprint field as if you are going to edit
4. hover over the current sprint link
5. bottom-left will display the 'url' w/ the SprintID=xx. remember this number.

Use Bulk Update:

1. create a JQL that result in at least the one story you just found the SprintID for
2. Select Bulk Update
3. Select ONLY the story(ies) you wish to change the sprint for
4. Edit issues
5. Enter the SprintID number you retrieved earlier
6. Save the change

[Kate Tokar]

This happened to us a couple of times now. We have a single board per the whole company, and we work kind of on "Scrum-Ban" basis. So we always end up having a lot of incomplete issues by the end of sprint. So, there has already been 3 instances, when ~2/3 of incomplete issues went to backlog instead on next sprint, although we explicitly selected next sprint. And I had to then using query, find all of those and bulk-move them to the necessary sprint.

[Lee Correll]

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.

[Lee Correll]

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.