Somehow every new sprint, we have existing CLOSED tickets that get transferred to the new Sprint.
It is happening, when someone is closing old Sprint and opening new Sprint.
Have a look at one of these "closed" issues. Were they in the far right hand column of the board when the sprint was closed (look at the status at the time of closing and the board column mapping). Also, did they have one or more sub-tasks? If they do have sub-tasks, check the same for the sub-tasks - were they in the far-right hand column too?
Statuses "Closed" and "Resolved" are Unmapped in Board. Column "Done" contain tickets only with status "Ready for Release". Tickets had been closed before Sprint has been closed. Such tickets have sub-tasks and/or linked issues which are not "Closed" but "Ready for Release"/"Opened". Also i have found tasks which are in progress and moved to new sprint, those tasks contain sub-tasks in "Opened" and "Ready for Release" states, all those sub-tasks also automatically moved to new Sprint.
Right, that makes sense.
For an issue to be seen as closed by a sprint, it has to be in the right-hand column of a board.
Your closed and resolved issues, and the ones that have sub-tasks that are not done, are moved to the new sprint because you've told JIRA they are not done.
I actually have the exact same problem, BUT my board has the a done column with all the closed and resolved tickets mapped correctly. Basically the sprint closed, a new sprint was started and over 200 tickets that were closed from months ago (several sprints past) somehow were added to the new sprint automatically. I checked the history in the individual tickets and none of them have an action listed that put them in the new sprint. And the board filter hasn't changed and there's nothing in the audit log to explain how it happened. Very concerning that we have to manually update each individual ticket since bulk update doesn't allow us to remove one value from a series of sprint values per ticket :(
My team is experiencing this issue too and it's beginning to cause problems. A solution to this would be great. We can't even see these random other tickets that are going to be added before we start the sprint, because they're not even listed in the filter of the board we're creating the sprint from (because the random tickets are from another project).
Unfortunately, you're wrong, it's not that simple.
There are tickets which have been closed / done / resolved from other projects being added to newly created sprints.
I've checked other solutions which have suggested the mapping of statuses and it all looks to be correct.
The other problems is that somehow we're getting crossover, i.e. tickets from project B are somehow ending up in a new sprint of project A. How can we groom our backlog and plan upcoming sprints if they are continually getting messed up?
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs