Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

Recognition

  • Give kudos
  • My kudos

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?

2 answers

0 votes

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:

  • 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?

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...

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?

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!

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Posted in Jira Core

How to manage many similar workflows?

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 ...

3,962 views 11 5
Join discussion

Community Events

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

Events near you