They should move to the next open sprint, yes. This is taken from the documentation:
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.
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.
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.
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot