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'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?
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!
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)
We are having the same issue even today.
Two different board, separate issues.
- Close current Sprint
- Open new sprint
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.
Your boards are looking at the same sprint. You'll need to get board 2 to stop including the sprint, and use its own.
Sprints belong to boards not projects. If you need people to run different sprints, you need to define those sprints separately on different boards.
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
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?
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.
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.
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?
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.