"A sprint from a different board can't be a destination for the remaining open issues" error prevents the setting of the destination sprint


Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Selecting a specific board to automatically move open issues to a new board when a sprint finishes results in the error "A sprint from a different board can't be a destination for the remaining open issues" due to that the new destination board has a different origin board.

Environment

  • Jira Data Center
    • (Version 9.12 at the time of writing.)
  • Option "Parallel Sprints" has to be enabled for the "Start and complete sprint automatically" checkbox to appear in the Edit sprint box.
    • Administration > Applications > Jira Software > Jira Software configuration 

Diagnosis

You are using parallel sprints and you are setting your sprint to start and complete automatically. When saving you get an "A sprint from a different board can't be a destination for the remaining open issues" error and the edits can't be saved.

Cause


The board you want to move the remaining open issues to belongs to a different origin board.

Background:

  • Sprints are always owned by a specific board. This is referred to as the sprint's "origin board".
  • Boards do not belong to any specific project. Instead, the board-project relationship is computed dynamically based on the board's filter.

The reason for this error is that if the two board do not have the same filter and scope, this would mean that you would not be able to trust that the list of issues in the new sprint will be the same as in the old sprint. In order to avoid this kind of inconsistencies, Jira will refuse allow that situation to occur.


(lightbulb) If you copy a board, the new board counts as a new origin board. Sprints created from it will have the new board as origin board. Sprints created from the old board will have that board as its origin board. 

How to check the origin board

If you are unsure which origin board a particular sprint belongs to, you can use the below SQL query to find that out. (Replace <Sprint Name> with the name of the sprint you want to check.)


SELECT rv."NAME" AS origin_board_name, rv."ID" AS origin_board_id, s."NAME" AS sprint_name, s."ID" AS sprint_id
FROM "AO_60DB71_RAPIDVIEW" rv
         JOIN "AO_60DB71_SPRINT" s ON rv."ID" = s."RAPID_VIEW_ID"
WHERE s."NAME" = '<Sprint Name>';


How to reproduce

You can try this behaviour out by following these steps:


0. Check that "Parallel Sprints" under Administration > Applications > Jira Software > Jira Software configuration is on to enable the "Start and complete sprint automatically" checkbox. (Parallel Sprints are off by default.)

1. Create a sprint on Board A

2. Create a new board based on the same project as in Board A. We will call this board Board B.

3. Create two sprints on Board A: Sprint A1 and Sprint A2

4. Create one sprint on Board B: Sprint B3
(Sprints A1 and A2 will then have Board A as their origin board. Sprint B3 will have Board B as its origin board.)

5. Click Edit sprint for one of the sprints on Board A and select Sprint B3 from the dropdown.

6. The "A sprint from a different board can't be a destination for the remaining open issues." appears because that sprint has another origin board, namely Board B.

Solution

For the reasons mentioned above, it is not possible to use a sprint on another board as an automatic destination for open issues at the completion of a sprint. The destination has to be a sprint on the same board.

As the organisation of boards and sprints are best done by the stakeholders themselves, there is no particular recommendation on how this should be handled other than that this requirement has to be satisfied: The new and the old sprints need to belong to the same board.



Last modified on Feb 6, 2025

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.