We had a situation where a specific sprint started to appear on 2 agile boards, and it looked to us like the board that "owns" the sprint had changed (of course we could be missing something obvious on all this). Our specifics below (I've changed the names of the boards & sprints for simplicity):
Does anyone have any ideas / suggestions? Otherwise we'll submit a support issue in case it warrants a closer look. (Although it didn't appear to be required, we did reindex and ran the integrity checks ok after seeing this problem. We're on Jira 6.2 / Jira Agile 6.6.13 / MySql).
Sprints are actual Global objects, so they aren't technically owned by a board. If the filter for a board brings in issues that are already associated with a Sprint, that Sprint is going to be associated with that board as well, and show up as you've described.
This is important to understand, because actions you take with a Sprint on one board that could impact other boards (and teams) as well. I would recommend having descriptive names for your Sprints to avoid any confusion.
Thanks Dave, I appreciate it. My assumption is that a sprint won't be displayed on a board if it has no issues in it (per that board's filter) - unless the sprint was created on that board, in which case it will show up regardless of whether it has any issues in it or not (which makes sense, and may explain why the db tracks the original board ID for each sprint). We didn't want the anomalous sprint to be displayed in our "board 2" (when the sprint was originally created in another board), so we emptied all "board 2" issues out of the sprint (then verified through a separate JQL query), and the sprint unfortunately stayed visible (which led me to investigate which board ID was associated with the sprint in the sprint database table). We didn't want to delete the sprint, since the other board had created it & was using it.
Is the board where you're unable to start your real sprint the same board where you initially created the (now empty) sprint? I don't know if you're able to delete the empty sprint (a "delete sprint" option may be available), but be very careful in case the empty sprint might be used by / visible on any other boards. Another alternative you might be able to explore would be to create a copy of the agile board (where the "empty sprint" should not appear if it's truly empty), then you might be able to use this copy to kick off the sprint that you really want to start. I'm not certain if it would work or if there would be any side effects, but you could investigate.
We had the same problem today: we found that the sprint in our board had vanished, and all the issues in that sprint had magically transferred to another sprint which already existed in a different board.
@David Nicholson I appreciate what you are saying about sprints appearing in a board only if they contain issues matching that board's filter, and that makes perfect sense ... but AFAICS this doesn't come close to explaining the main issue reported by @Andrew Fisher4 and experienced by us today, i.e. of having a sprint spontaneously vanish (or at least get renamed to the name of a different sprint which already existed).
So please can you take a bash at explaining that? To me it feels very much like a bug in Jira. Sprints should never spontaneously vanish or get renamed!
Furthermore, if sprints aren't owned by a board, I'm wondering what it meant when @Andrew Fisher4 said this?
In the db, it appears the sprint is now "owned" by board 2 (per RAPID_VIEW_ID in the AO_60DB71_SPRINT table).
Quick update - it has been been suggested that this was caused by not having parallel sprints enabled:
even though without this enabled, we were still able to happily have multiple sprints all running in parallel for several months with no issues before this weird behaviour surfaced. Can anyone explain that?
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot