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?
This is super frustrating as I have recently been encountering this problem as well. When planning for upcoming sprints, I'll create an 'on deck' sort of sprint to start bucketing items for the next sprint as we're planning and grooming our backlog.
For some reason, issues that are in a completely different project (one that hasn't been used in 3 years), are getting added to these sprints. Looking at the detailed activity history on the affected ticket, it only shows the sprint value being blank then another line item that says I added it to the sprint. I did not do this! I can't even remove the sprint value since it's not even a configured value for the affected ticket. Makes no sense at all.
Hi Mimi, unfortunately despite all the people reporting they have this issue even with the correct board settings advised by Jira, the Jira folks seem unable to accept that there is an underlying issue here that needs investigation and resolving (please Nic, do investigate this continuing bug).
The biggest thing I've found that helps is always ensuring there is a pending backlog/grooming sprint to send any unresolved tickets to when closing the current active sprint. We've had zero crossover/unexpected tickets since using this approach (and I can clearly see it still happening when someone forgets).
Hope this helps!
I am looking at the same issue right now.
- A bunch of closed tickets that have not been modified in a long time were added to a newly created sprint.
- Modification date has not changed (old tickets still show 2018 as updated/resolved).
- Issue Activity does not show any recent change in values for Sprint field.
- Old issues turn up in the right most column based on their status.
- No subtasks in many of these old issues.
We are phasing exactly this problem. Out of the blue very old tickets (about 60) show up in the just started sprint in the done column. The shown tickets are about two years old. Opening such an old ticket does not show any modification in the history for the last years. I see for example ticket-64 while creating a new one today will be ticket-2978
If I look at the 'Sprint' value of ticket-64 it shows the name of the current sprint what is: "Sprint 86 wk46_47"
The string "Sprint 86 wk46_47" did not exist at the time ticket-64 was actual and now it is suddenly filled in. So, to me this looks like Jira is applying changes to its internal database by mistake. A bug. It seems to happen at sprint closure. The updated tickets are not related to the closed sprint or the backlog. The modification are done without a trace, at least not on user level since history is not changed at all.
I really hope this ticket, defect report, is taken seriously
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events