How can I prevent colliding linked sprints across two projects?

[Casey Gould]

This question from 2018 explains the issue pretty well. Two sprints end up somehow linked in a way that one being active prevents the other one from starting. Last time, I followed the directions to label tasks and recreate both sprints, but that's not sustainable.

There are two projects: A and B.

The board for team B is just project B.

The board for team A is defined as A and B.

The leader of team A claims that it works fine if the sprints are started in a certain order. They claim that the only problem is that the leader of team B started the sprints in the wrong order.

I can't find any evidence that this should work at all, and I can't keep cleaning it up for them. The person who supposedly set this up has left the company.

Is this even something that should hypothetically work, or do I need to tell team A to take project B off their board definition?

[Walter Buggenhout]

Hi @Casey Gould,

If you just forget about Jira, projects and boards for a second and just look at the concept of a sprint and how it should help you organise work, I might be able to clarify.

A sprint is a concept that lets you organise work for a team over a certain period of time - usually two weeks if you follow copybook scrum. It is designed to create focus for the team on just the work that needs to be done in that timeframe. And so, anything that ends up in the sprint that should not be there, basically interferes with that goal. So, essentially you would not really want work for another team to appear on your sprint nor sprint backlog if you have that in mind.

Now enter Jira and the setup you describe. The main problem here is that you have issues from your project B that appear on both boards. For some reason, it was decided that some issues are relevant for both Team A and Team B, but I'll need to look at you for the why behind that.

This is a problem because sprints appear on a board because they get assigned to issues that match the board filter. If you have an issue that appears on both Board A and Board B, it is perfectly possible to add that issue on a sprint that was created on either board. And then, funnily enough, as soon as this happens in e.g. Board B, the sprint assigned to that issue will suddenly also pop up in the backlog view of Board A. The only reason for this being the fact that is assigned to an issue that appears on the board.

So, the best you can do to avoid mishaps, is create a clear separation between the selection of issues on both boards. As sprints are available across your entire Jira product, people will still be able to add issues to sprints from other projects or boards when they edit the sprint field directly from the issue view, but that scenario is a lot less likely to happen.

Hope this helps! 

[Casey Gould]

I'm very familiar with the concept of a sprint and also don't think it makes sense as it's defined today.

Unfortunately, I need something stronger to push for permanently untangling the boards, and the leader of team A is adamant that everything was perfectly fine until some manual process (undocumented, of course) wasn't followed.

[Mikael Sandberg]

There is no way to prevent it from ever happening, but you can minimize it by educate your users. I always recommend to only assign the sprint from the backlog but using either the drag-n-drop option, or right-click and use the quick move option. That way you guarantee that the issue are only added to sprints belonging to that specific board (unless you already have a sprint that crosses multiple boards).

[Casey Gould]

Thanks, Mikael. If the answer is that it hypothetically could work, I think the problem I'm left with is the finger pointing on who's doing what wrong. 

[Mikael Sandberg]

You can always check the history if an issue and see when and who added the sprint to the issue that is causing problems. I would also check the filters on the boards, I have had teams the made the filters so broad that they spanned all our projects because it was basically just labels = something and nothing else.