Sprint showing up on multiple boards, messing up velocity

[Casey Gould]

Background:

We have two teams with two different projects and two different boards - A and B.

Team B noticed that their velocity stats have been weird, and realized that recent sprints from Team A are getting pulled into their calculations.

What we know:

1. Bug Ticket X was created by team A.
2. Team A had it in three of their sprints (not ideal, I know) before deciding it should belong to Team B.
3. The ticket was moved from project A to project B, so the key currently displays as project B.
4. Ticket X is now part of team B's current sprint. It is not part of A's current sprint.
   The Sprint history is: A1, A2, A3, B4. 

The problem is that the ticket seems to have brought all the "baggage" of those 3 sprints with it to Team B.

I suspect that because the ticket (now project B) is the only project B ticket in Sprints A1-3, the calculations are acting like Team B had 3 sprints at 0% completion.

Additionally, Team A's Sprints 1-3 are now displaying as part of Board A and Board B. Sprints A1-3 are also showing up under /reports/sprint-retrospective on Project B.

If I click on Sprint 2 from Ticket X, I get this page:

There's a possibility we're running into this problem again where sprints aren't sourced from the board we thought, but I don't think so because it shows as existing on two different boards.

What we've considered:

• Jira answers seem pretty clear that we can't delete Sprints A1-3 for Team B without also deleting it for Team A. Not an option.
• If we redefine the filter for Board B to exclude ticket X, could we kick the ticket out of the stats?
• If we send the ticket back to Project A, will the Sprints A1-3 leave with it? We could then create a Team B clone to do the work.

Any advice on how to get Sprints A1-3 out of Project B or additional information we should provide?

[Mikael Sandberg · Accepted solution]

Correct, if you delete the sprints that will affect both teams. Yes, you could redo the filter, but that only fixes the stats, not the underlying issue. Yes, if you move the ticket over to project A it should remove the sprints from project B. 

You could very well run into this issue again, it usually happens when a user assigns the sprint from within the work item detailed view, and not paying attention to which sprint is selected. I always recommend assigning the sprint from the backlog, that is the easiest way to avoid this.

Note that sprints are not board/project specific, and before Atlassian added a checkbox to only show sprints created in the current project when assigning it in the detailed view, this was very common.

[Casey Gould]

Hi Mikael - I think I recognize you from a previous question I had about a different pair of teams tangling their sprints, thanks!
This is the first time we've noticed it, so we'll go with the one-time fixes. 

[Casey Gould]

Kicking the ticket back and cloning it (not checking the clone sprint values box!) did it. Not my favorite solution, but I get why it works.

[Trudy Claspill]

Adding to this...

1. Sprints are not limited to containing issues from the board in which the sprint was created. Any issue can be added to any sprint, if you have sufficient permissions.

2. An issue will retain the history of sprints it was in that were completed with the issue still in the sprint, regardless of whether the issue is moved to another project.

3. An issue can be in only one Active or one Planned sprint at a time.

Because of 2, when you moved the issues to another project they took their sprint history with them.

Because of 1 and 3 a scrum board will display any Active or Planned sprint to which an issue has been assigned for any issue within the board's filter scope. That way when you are in a board and want to add a given issue to a sprint, you can see that it is already in another active or planned sprint in another scrum board.

Also because of 1, 2, and 3, when you look at the reports for the scrum board you will see all the sprints (completed and active) that are associated to the issues within that board's filter scope.

If you move the issues back to the original project the sprints will no longer show in Project B's board. But the issues also will not show up on Project B's board because they would no longer be within the scope of that board's filter.

You can, technically, add the Project A issues to the Project B sprints. However:

1. Then the associated sprint from Project B would show in Project A's board.

2. The Project A issues assigned to Project B's sprints would still not be visible in Project B's board.

The only way to prevent the cross-pollination of sprint data is to remove the Project A issues from the old sprints. Normally that can only be done by reopening the sprint, but I do seem to recall seeing posts about a method to remove issues from a Closed sprint without reopening it.