Problem Definition

When a user completes an active sprint, they have an option to send the incomplete issues within that sprint either to the backlog, or into another sprint.

However, if the active sprint is being closed from within a Board that does not have full visibility of all of the incomplete issues in the sprint (i.e. if the board uses a more restrictive filter than the Origin Board of the sprint), those not-visible incomplete issues will still be sent to the Backlog, even if the user chooses to send them to another sprint.

This is intentional - issues should not be affected when they aren't present on the Board being worked on. However, we cannot keep them in the active sprint either, since it's being closed. Therefore, they are sent to the backlog.

However, this is not clarified either in documentation, nor is the user closing the sprint warned of these not-visible issues.

A consequence of this is that users may later find issues which are not complete, yet belonged to a sprint which has since been completed. It is not easy for users to understand why these issues aren't automatically in an ongoing sprint and are still sitting in the backlog.

Note: as long as the board filter considers the issues, the issues will not lose their sprint, for example if the issues are considered by the board filter but their status is not mapped in the board columns, this will not cause the behavior described in this FR, and the issues will be moved to the next sprint as expected.

Suggested Solution

As this is an intentional, yet not documented or explained to users, we need to:

• Improve the existing documentation at Completing a sprint
  • JSWSERVER-20277 : Update Documentation - Clarify that when completing a sprint, sending incomplete issues to the next sprint will still send issues to the backlog if they are not visible from the current board.
• Provide additional messaging during the Complete Sprint operation. This could include any of the following:
  • Explaining how many issues are not visible in scope of the current Board
  • A link to the Origin Board of the sprint (so that the user may close the sprint there instead)
  • Clarify what will happen to the not-visible issues should the operation complete
• Add a clear message indicating on which board was the sprint closed. This helps track down discrepancies in fboard filters and identify why issues may or may not have been sent to backlog or next sprint, as well as indicating what option was selected (Send to next sprint, or send to backlog).

Workaround 

Avoid closing a sprint from a board that isn't the Origin Board of the sprint.

Determine the Origin Board via the Workaround steps in JSWSERVER-13265 : Provide UI method to identify origin board for a sprint.