Sprints are "linked" across projects -- how to unlink?

[Mirko Raner]

I am aware of this question, but, frankly, other than emphasizing and re-emphasizing that "Sprints belong to boards not projects" and "Issues do not belong to boards", the given answers provide little practical advice as to how the problem can be fixed. (Also, I'm not 100% that my issue is really the same.)

So, here goes my problem: we originally only had one project, SP, but then later added two more projects, FE and HF. Each project is supposed to be on it's own sprint cycle. On the "Projects" page I see all three projects, each with their own board. When we originally split out the new projects from the original SP project, everything went well for the HF project, but the FE project and the SP project are still somehow linked. Specifically, it appears that both projects share the same sprint objects. This manifests itself in the fact that starting an SP sprint will also start the FE sprint (and vice versa). Also, when I change the name of the FE sprint, it will also change the name of the SP sprint, and vice versa. So, for all intents and purposes, it appears that the FE sprint and the SP sprint are really one and the same object (though they do show the correct issues in their respective boards). This linkage appears to be retained for all future sprints as well. As I stated earlier, each project has its own board, so I'm not sure what else to check.

How can I separate the SP and FE sprints from each other?

[Kirk Gould]

This is issue is created when a user is editing a Story and picks the wrong Sprint for a Story. 

They are editing an issue in Project A.  They click on the Sprint Drop-down and Sprints from Project A, B, and C are all visible in the drop-down.  In fact, there may be three sprints all named: Sprint 1.  So the user accidentally selects the wrong Sprint (which belongs to Project B), but they don't know they are selecting the wrong one.  Everything looks fine on both boards....for a while...because visually they are identical (the Sprint Names.)

Then they start to add more Stories to their Sprint on their own board...and it still looks fine, but the problem is, these are actually the Same Sprint in two different Boards that belong to different Projects.   So now when a person Starts the Sprint on Board A, it starts the Sprint on Sprint B at the same time. (much to the Chagrin of the other Scrum Master)  (The contents of the Sprints look different depending on which Board you are looking at, but the Sprint is literally the same.)

If you change the name of the Sprint on one board, it changes it on the other...but you won't know that.

If you Complete the Sprint on one board, it Completes it on the other...but you won't know that.  It is like wiring a light switch to your neighbor's house and when you or your name flip their switch, it changes the lights in both houses.

To fix this requires between 1 and 2 hours...per situation.

You do a JQL query to identify which items are in the specific sprint (through using the Sprint Number in the JQL). Then you use Bulk Edit to blank out the Sprint for all the Stories...after you put in a label to remind you of which Project the Stories are supposed to be in.

Then you create a new Sprint in each Board from Scratch.

Then you put the appropriate Stories in the appropriate Sprints on their Boards using Bulk Edit to update Sprint (using the appropriate Sprint number in the JQL search) (Sub-tasks follow)

Then you delete the empty, contaminated Sprints.

In the future, new Sprints will be created from the Non Cross Contaminated Sprints.

Please note:  This solution is not fun. It gets even less fun when you don't discover this for a few months and you have to go back to old Sprints and replace them and Open and Close the Issues within them to get your Committed and Completed numbers to be accurate.

We are currently looking for a way to prevent this from happening...as you can imagine!

[Casey Gould]

Thank you!

Updating one sprint and seeing the update of the other name change was what confirmed for us that this was the issue.

Note: To bulk add a sprint, you need the sprint ID. I got this by typing

sprint = "Name of Sprint" 

into JQL, which will display the Sprint ID in parenthesis at the end of the auto-complete suggestion.

Our problem was fresh, so it took me ~30 min.

[Asghar Ali]

It worked, thank you

[Kelley R]

No way to prevent it from happening that I can find. Here is my resolution path, synthesized from several tickets and tested repeatedly. There may be better or faster ways, but I haven't found them. 
1. In both projects, create new sprint. Suggested naming ID = oldsprintname_1
2. Identify contaminated sprints sprint ID. 
3. JQL search "Sprint=SprintID#"
4. Bulk change all results
4a. Add label - (suggested - this is just so you have a backup to find your issues if this doesn't work correctly) contaminatedsprintID#
4b. Change Sprint to the new SprintID
4c. Confirm
4d. Do this on both contaminated sprints
5. Attempt to close or delete now empty sprints.
5a. You may be met with a permissions error, particularly if the board filter is a "complicated filter" ie. includes multiple projects. To resolve, make sure you have manage sprint and schedule issue permissions in ALL projects included in the filter.
6. Start new sprint
6a. You may be met with an error "Includes issue(s) currently hidden by a Quick Filter or the Instant Filter."
6a1. JQL search for the sprint that won't open "Sprint in (sprintID#)". Find the issue(s) that is/are in the wrong project. Delete it. (if it’s unimportant. If it’s important, export it and reimport it to the correct project, making sure not to relink them)
7. Verify both projects only have one active sprint.

[Asghar Ali]

Thank you so much, this solution worked for me.

[Dick]

After the splitting of project A into project A and B and moving appropriate issues to B, we had the same issue as the original poster. In both project A and B we had sprints defined: Sprint 1, Sprint 2 and Sprint 3. We solved it in the following way:

In project A, we entered three new sprints named Sprint 1A, Sprint 2A and Sprint 3A.

In project B, we entered three new sprints named Sprint 1B, Sprint 2B and Sprint 3B.

In both projects, we then moved (selecting, then right-click menu move) the issues of each Sprint x to their respective newly defined Sprint xA and Sprint xB. After all issues were moved, we deleted the Sprint 1, Sprint 2 and Sprint 3 in project A, which also triggered their deletion in project B (as they were obviously linked together in a non-desired way). 

This unlinked the dependency between the sprints of both projects.

[Laura Dunne]

Any solution to this issue? Two projects sharing the one sprint. 
How can we separate the sprint from the two projects. 
I need two projects, two separate sprints.. 

[Alex Christensen]

Have you checked the queries that the boards use? If you want the boards to separated between projects, I would also make sure that the query the boards use are filtered to a specific project (SP, FE, or HF). In the same way that issues do not belong to boards, boards do not belong to projects.

I'm not 100% sure if this will fix the issue, but my thinking here is that because an SP issue and an FE issue can appear on the same board, they can technically "share" sprints.

Hope this helps!

[Mirko Raner]

Thanks for the pointers, @Alex Christensen

I looked into this, but this appears to be all set up correctly, here are the board settings:

• SP board:
  • Location: project SP
  • Filter Shares: project SP
  • Filter query: project = SP ORDER BY Rank ASC
  • Projects in board: SP
• FE board:
  • Location: project FE
  • Filter Shares: project FE
  • Filter query: project = FE ORDER BY Rank ASC
  • Projects in board: FE

So, it looks like each project has its own board, with a filter that matches only that particular project and no additional shared projects. Also, we've never seen FE and SP issues appear on the same board.

Is there any other place I should check?

[Mirko Raner]

It appears that I finally managed to create separate sprint objects for our next set of sprints, the new SP sprint was initially created as "FE Sprint x",  but after renaming it to "SP Sprint x" it appears to maintain a separate identity from the actual FE sprint. Let's see if it stays that way once we kick off the new sprints...

[Julian W]

Hi @Mirko Raner,

I'm experiencing the same issue as you. Are you able to confirm that simply renaming a newly created sprint in Project SP's board to be distinct from a sprint name in Project FE's board was successful even after the sprint commencement and completion?

[Steven Carroll]

We had a new sprint and it reverted to creating only a single sprint for two projects. Unable to resolve as yet.....

[Tara Freedman]

Same issue here. I renamed a newly created sprint--but they are still linked. I can't stomach the amount of effort this is going to take to go back in time and fix all closed sprints.

We do have 1 board that shows both sprints as the teams were merged for a time due to lack of management. Now however we want to be fully separated.

[Mahipal Annam]

I am experiencing same issue, sprint is linked to two projects, i originally had only one project when the Sprint is started, later created another project for different service.  The Sprint is  now linked to both projects, changing it's name per new project naming convention in the new project is changing name in the original project.