Jira scrum board - 'complete sprint' action moves some stories to backlog instead of next sprint

[Amir Katz _Jira Admin_]

I have a scrum board. In the current sprint there there are ~90 completed stories and 8 incomplete ones.

When I invoked the 'Complete Sprint' action it prompted me what to do with the incomplete ones. I chose 'move to next sprint' and chose the specific sprint.

Out of the 8 stories, 5 stories were moved to the selected sprint, as it should be, but 3 stories were moved to the backlog.

AFAIK, the 'complete sprint' action does not care about the columns in the board - it decides which action to take on each story based solely on the Status Category of each story.

Any idea why the different behavior?

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

The "complete sprint" action absolutely cares about the columns.  If something is in the last "done" column it does not move to the next sprint, because it's done.

I suspect what you are seeing is that the three issues that went back into the backlog were items that had not moved to any in-progress column - no-one in the team has even looked at it.

8 issues incomplete tells us that you have a problem with the team and you need to review your processes.  There should be none moving to the next sprint, it is an exception and it needs explaining so you can improve.  The usual reason is poor estimation, undersizing stories so the team takes too much into the sprint.  One issue every couple of sprints is probably going to happen when people get sick or there is an emergency that takes people out of the team, but 8 issues is very much "your team is failing somewhere"

[Amir Katz _Jira Admin_]

Thank you, Nic. BTW, I have been in the Atlassian Community for >6 years, but under different user names...

[Amir Katz _Jira Admin_]

Link to the documentation: https://support.atlassian.com/jira-software-cloud/docs/complete-a-sprint/

[Nic Brough -Adaptavist-]

Um, yes, that document says all the issues must be marked as "done", which is "they are in the last column of the board"

[Amir Katz _Jira Admin_]

@Nic Brough -Adaptavist- , others, of course, are welcome to chime in...

Some related questions:

1. What happens if I have two columns in the Scrum board which contain "green" statuses (green means StatusCategory=Done)?

2. When the documentation uses two terms: "completed issues" and "Done issues".

I assume those are interchangeable.

3. I also assume that "Done" means that the status is in category "Done" and not in status "Done", as Jira admins can rename the "Done" status to any name they want (e.g. translate to another language, use "Completed", etc.)

4. I do wonder whether these terms actually refer to the issue's resolution - several parts of Jira refer to an issue as done if it has a non-empty resolution (e.g. that dashboard gadget 'Created vs. Resolved'). OTOH, the Scrum board does not care about the resolution...

[Nic Brough -Adaptavist-]

1. The status category is irrelevant.
2. Yes, they are interchangeable terms
3. No, that assumption is wrong.  As I, and the docs, said, you tell Jira that an issue is done by moving it to the last (rightmost) column on the board.
4. That's a common misunderstanding, because Jira does it in two ways, and they can be inconsistent. 

Before we had Jira Software to support Agile processes, Jira had a very simple binary flag with the resolution field:

• If the resolution is empty, the issue needs more attention. 
• If the resolution is set to anything (including resolutions called things like "not done", "unresolved", "to do" etc, the name of the resolution is irrelevant), then the issue is "done" - needs no more effort.

Most of Jira still does it that way.

Jira Software boards are more flexible.  A board represents a team.  The team moves issues across a board until they are done.  The done column is the last on the board because it means "the team can't move the issue further to the right, so it needs no more attention from this team".  

Most workflows for Software projects should keep the resolution in line with the done column - when an issue moves into the done column, then set the resolution, so that the rest of Jira can report it as done with. 

But in some cases, it makes sense to set the resolution before the board sees it as done, and in others you would not set it at all.  One team's "done" might be another team's "to do".  In a non-Agile process where you have a development team and a tester team, then the developer's "done" is the tester's "to do".  And the tester's "done" is probably your production support team's "ready to deploy".  You don't want to set a resolution until the issue is fully tested, or even deployed to production

[Amir Katz _Jira Admin_]

Thank you, excellent explanation!

[Rebekka Heilmann _viadee_]

Have you looked into the issues' history?

[Amir Katz _Jira Admin_]

Thanks - yes, I did, nothing there