You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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!
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
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.
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.
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!
Thanks for the pointers, @Alex Christensen
I looked into this, but this appears to be all set up correctly, here are the board settings:
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?
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...
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.
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.