Strange behaviour when attempting to use multiple sprints

[Cary Lewis]

We recently switched to a devops pattern where multiple teams are working within the same jira project, and and team will manage their own sprints. We add components to the stories, etc. to isolate stories amongst the teams.

When attempting to create multiple sprints, we are encountering strange behaviour:

1. when we drag or move an issue from the backlog to a created sprint, the story count on the board (which filters by component) looks correct, but when we attempt to start the sprint, many more random tickets are reported as being included within the sprint.

2. When attempting to delete the sprint, so that we can retry, the delete sprint does not return all tickets to the backlog. We have had to delete the sprint multiple times before it actually disappears.

Does anyone have any ideas as to what might be going on?

[Trudy Claspill]

Hello @Cary Lewis 

Jira does not limit the issues that can be added to a sprint to only the issues in the board where the sprint was created. Any issue (in a Company Managed project) can be added to any sprint (in any Company Managed project Scrum board).

The display of issues in a Sprint in a given board will be limited to only the issues that are within scope for that board. An issue not in scope for that board may be added to the sprint and you would not see that issue shown in the sprint on that board.

You can find out exactly what issues are in a given sprint by using the Advanced Issue Search screen to search for issues in the specified sprint.

One factor that can lead to this sort of cross-sprint population is if you are not using unique names for your sprints. Jira does not require the displayed name of the Sprint to be unique. If you have multiple boards using "Sprint 1" as a sprint name, your users may be adding issues to the "Sprint 1" that belongs to a different board.

You should be able to review the issue history to see who added the issue to a given sprint, which would enable you to go back to the responsible party to ask why they added the issue to the sprint.

You might also want to review the Automation Rules to see if there is one that is automatically adding issues to sprints.