Sprint appears to be owned by a different board from the one that created it

[Andrew Fisher]

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):

• We have multiple agile boards
  • Board 1 had its own sprints (e.g. sprints 1a, 1b, 1c), with its own issues using a project-based filter.
  • Board 2 had its own sprints (e.g. sprints 2a, 2b, 2c), with its own issues, using a filter based on a different Jira project.

• Problem
  • On board 2, we noticed that "sprint 2b" was now named "sprint 1b" (showing the same issues that were previously shown in "sprint 2b").  At first glance, it was as if the name of the sprint was edited. (Looking at example issues' histories, there was nothing in the history that showed them being changed from one sprint to another).
  • We found it's the same sprint across the 2 boards (i.e. the same sprint ID, with different issues displayed on each board, correctly based on each board's filter).
  • In the db, it appears the sprint is now "owned" by board 2 (per RAPID_VIEW_ID in the AO_60DB71_SPRINT table).
  • There were no edits to the issues themselves (or the boards' filters) to cause them to move across boards / filters / sprints.
    

• Our workaround for now
  
  • We wanted to avoid using "sprint 1b" on board 2
  • So we created a new sprint on board 2, and moved the issues from "sprint 1b" into this new sprint. We noticed that "sprint 1b" (now empty per the board's filter) stayed visible on the board
  • We created a copy of board 2 (so "sprint 1b" wouldn't show up), and started the new sprint.

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

Thanks!

[Tiago Palhoto]

When you create a scrum board, you define a filter that will provide the native data that the board will always display. Lets say you create the filter over PROJECT A. 

When you open your backlog, you will see all the issues under the backlog section, since they haven't been assigned to any sprint.

Let's now say that you create sprints  "SPRINT 1 PROJA" and "SPRINT 2 PROJA". Internally, those sprints will be linked to that particular board. This is why, when they are VIRGIN, they are only seen inside that board an nowhere else. However, those sprints willl be available for anyone. This means that someone can assign your sprints to their stuff...but you can also assign your items to their sprints.

So, let's supposed that you have dragged some of the items that you have in your backlog to the sprints SPRINT 1 PROJA and SPRINT 2 PROJA. This will be clear about what you will see. Now, let's supposed that you edited an element and manually assigned one of those issues to a sprint that has nothing to do with yours...for instance SPRINT 1 PROJX. The next time you go to your scrum board, you will see not only the SPRINT 1 PROJA and SPRINT 2 PROJA but also the SPRINT 1 PROJX with ONLY your item there. 

So, the scrumboard will always display a container for the sprint that are assigned to the issues that are in the scope of the filter that it supports (and also your permissions). But because it's limited to those items, you may see different versions of the same sprint. So, In the previous example, you will see the the SPRINT 1 PROJX with only your item there, while the board that is tackling the PROJX will see the SPRINT 1 PROJX with their items there (assuming they don't have PROJECT A in their filter).

Hope this helps.

[Dave]

Hi Andrew,

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.

Cheers,

-dave

[Andrew Fisher]

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.

[Laurie Trindle]

This is exactly what we're looking at now. The sprint is empty on one board (no issues meet the board criteria), and since it's at the top of the list, it's blocking that board from starting its sprint.

[Andrew Fisher]

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.

[Joshua Mahoney]

We are experiencing this same issue. Has anyone found a better solution?

[aspiers]

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.  

@Dave 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 Fisher 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 Fisher 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).

[aspiers]

Quick update - it has been been suggested that this was caused by not having parallel sprints enabled:

https://confluence.atlassian.com/jirasoftwarecloud/using-parallel-sprints-797737030.html

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?

[Deleted user]

I was having the same issue :some one else's sprint appearing on my board. As there sprint was started I could not start mine. I tried to create a brand new board with the same filters (copy board as Andrew suggested) and it worked for me.

[PhillipS]

see my reply here, hopefully it will help:
https://community.atlassian.com/t5/Jira-questions/empty-sprint-stays-visible-on-scrum-board/qaq-p/53976#U771410