Sprint cannot be completed due to stories with sub task

[Jacqueline _Jacquie_ Wilson]

In one of my sprints, 3 stories had only a few steps left after development in progress and were in system test.  Due to a holiday offshore and a shortage of resources the team wanted credit for the work done in the current sprint; therefore, I cloned the stories and move the new stories to another sprint.  When trying to complete the current sprint a message received stated that "Sprint cannot be completed for Sprint 41 due to 3 stories have uncompleted subtask.  My question is since I placed the stories in Ready for Production and place the cloned story into the next sprint to finish the work can I move the subtask to the newly cloned stories?

Ex:  ACTXX-01 was in System Test and new testing resource joined the team and needed more time.  Cloned ACTXX-01 to ACTXX-02 same story but ACTXX-01 had subtask that was also in system test. 

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

The problem here is that you cloned the story instead of putting it back into a not-done status.

(By the way - " the team wanted credit for the work done in the current sprint" - that's not how Scrum works, you do not get partial credit for failing to complete a story you committed to.  Jira doesn't support you doing that in any useful way)

By definition, an issue cannot complete if it has open sub-tasks, Jira's "can't close sprint" is trying to force you to correct your data, either by getting the sub-tasks into the last column because they are done, or correcting the status of the issue to not-done. 

When you cloned stuff, you took the sprint data with it.  The clones will have to have their status corrected as well, for the sprint to be closable.

[Lisa Cutliffe-Taylor]

so, the idea is that a story must complete within the 2 week sprint and should not carry over?

[Nic Brough -Adaptavist-]

Indeed, yes.  A fundamental part of the Scrum process is that "the team only commits to delivering items that they believe they can complete in the sprint".

If an item is too large to be tackled in a sprint, then it should be broken up into smaller parts so that they can be done in different sprints.  Sub-tasks are not sprint items, they are fragments of sprint items, used to break down the item more for some reason, like "Alice is best to do fragment A, Bob for fragment B" or "these bits are in different modules", but they're purely for managing how the team looks at their stories, they're not for other people to define things)

In Scrum, rolling an item into the next sprint is an indication that something is wrong in your process.  The obvious ones are that your estimates are inaccurate, the team is committing to too much in the sprint, or finding they don't have the resources in the team that they should.  Obviously, there's also the unexpected - illness or emergency work distracting the team.  Part of Scrum is examining why issues roll over, and fixing the problem that caused it (or being able to explain it)