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?
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...
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!
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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