Starting sprint for one team(project), starts a second team's (project) sprint also

[George Stevenson]

I'm not sure what we have linked or setup incorrectly but for some reason when we start a sprint (scrum board) for one team/project a second team's sprint is also started. Almost as if the two teams or projects were linked to each other. Is there any way to break the link?

[Nic Brough _Adaptavist_]

Sprints belong to boards not projects.  If you need people to run different sprints, you need to define those sprints separately on different boards.

[Rowena Dayaram]

We are running different sprints, from different boards.  However, when trying to close the sprint from one board which has no open tasks, bugs or stories, the message displayed is that 'xxx issues were incomplete.'  The issues displayed are actually belonging to another board, running a different sprint

[Nic Brough _Adaptavist_]

Issues do not "belong" to a board, they are selected for inclusion by a board, and can end up on many boards.

Anyway, do the incomplete issues have any relationships with the issues in the sprint being closed?  An obvious one is if you include them in shared Epics?

[Rowena Dayaram]

No, the incomplete issues do not have any relationships with the issues in the sprint being closed.

However, there was an issue that was cloned between the 2, but that issue had been closed.

What we are really looking for is an easy way to identify cloned or other related issues between the boards so that we can unlink them so that we don't have this problem. 

[Nic Brough _Adaptavist_]

There is a relationship somewhere, the issues must be in the sprint they're blocking somehow.  There isn't a way I know of to get an issue out of a sprint while it remains in it like this.

[Rowena Dayaram]

Can you then please advise on how we should be copying items from 1 board to another?  We currently have dependencies, so we clone the issue from one board to another.  I'm guessing its the cloning that is causing it, so what would be the easiest way to copy the issue from one board to another?

[Nic Brough _Adaptavist_]

You don't.

Issues do not belong to boards.  There's no such thing as "copying from one board to another".  You have boards which select a range of issues to show you depending on their filter.

My best guess here is that you are not choosing to clear the sprint when you clone the issues.

[Rajesh Edara]

Me too having the same issue, as far as i know the link between two board sprints happens because of same Sprint ID, but I'm not sure how to resolve this issue, can someone help me in it?

[Jamie Scott]

We are having the same issue even today.
Two different board, separate issues.

Board 1

- Close current Sprint

- Open new sprint

Board 2

Impact: Opens the next sprint

Whats stranger is now I have Board 1 and 2 sprints open and if I change the Sprint Name or Goal, it is changing on the other boards.

[Nic Brough _Adaptavist_]

Your boards are looking at the same sprint.  You'll need to get board 2 to stop including the sprint, and use its own.

[Jamie Scott]

Hi

Both of our boards are looking at stories in their own sprint. 
There is no cross over in stories on each board

Humm

[Stacy Haller]

@Nic Brough  

Can you help with an issue I'm having?  We had a couple of projects that were entangled using the same sprint (2587).  It started as a holding area sprint and somehow it got moved up to an active sprint on one board (CS).  4 tickets from another board (BBC) had at one time been tied to that sprint in it's holding area time, but it the sprint remained on those tickets.  When that sprint was started in the main board (CS), it showed up on the secondary project board (BBC) because of the 4 tickets.

We were able to break those tickets away from the sprint and it disappeared from the secondary board.  But, we were still having trouble with an add-on because it was picking up the initial story points for those tickets and displaying them on the velocity chart.  I built a temporary board (BBC temp) & filter excluding those 4 tickets and it looked like everything was fine.

Now, I want to clean up that temporary board and filter, so I updated the main board (BBC) and filter to exclude those 4 tickets, but that isn't reflecting in the velocity.  I found out from the add-ons support area that they are using the rest api to get sprints associated with that board (BBC).  (rest/agile/1.0/board/XXX/sprint).  When I run this, I am still showing the 2587 sprint is associated to this board (BBC) even though the current filter excludes the 4 tickets that were tied in when that sprint started.

So, my question is - if a sprint belongs to a board, does that mean forever?  Why doesn't updating the filter change that link?

Thanks so much!

Stacy

[Nic Brough _Adaptavist_]

It's almost "a sprint belongs to a board forever" - the problem here is that you have had issues in that sprint, and that means they need to be reported on as such, so as long as you have issues that were part of a sprint for a board, then yes.

You'd need some way to clear out the historical sprint on those issues (I'm not sure you can do it directly, but scripting or REST apis might be able to do it.  I've not looked)