Sub-tasks

[Shari Fitz-Patrick]

I would like clarification of something.  I was under the impression that sub-tasks should be completed in the sprint that they are created.  However I have been advised that is not the case.  Could someone please advise.  Can we have a story that has say 10 subtasks.  5 are completed in sprint 71 and the other 5 need to be moved to sprint 72.  is that the right way of doing things.  thanks

[Nic Brough -Adaptavist- · Accepted solution]

You say: "I was under the impression that sub-tasks should be completed in the sprint that they are created." 

Yes, that is correct.   There are a couple of technical points to clarify in there, but it is the right impression.

It doesn't matter when the sub-tasks were created - before or during the sprint, or even after (on an issue that has not been completed in a sprint and will be going into another one later)

Sub-tasks do not go into sprints themselves.  They are only included in a sprint because their parent issue is in a sprint.  They are not sprint-items themselves, they are fragments of sprint-items.

>"However I have been advised that is not the case"

Whoever advised you of this probably needs to revisit their "Doing Scrum with Jira" training, because they are completely wrong.

Take your example of a Story with 10 sub-tasks.  What should happen is 

• Team commits to doing Story in sprint 71 (not the sub-tasks, just the Story)
• If the team completes all the sub-tasks, then the Story can be marked done, and it drops out of your backlogs when the sprint ends.
• If the team does not complete the story, then when the sprint is closed, the Story goes into sprint 72.  Because the Story is in Sprint 72 now, you can say that all of its sub-tasks are as well, because they are part of the story.  Their individual completion is irrelevant to the sprint, they're all in the next sprint because their story is.

It's also worth bearing in mind that issues moving to the next sprint should be an exception - the whole point of sprints is getting into.a cadence where you can deliver what you committed to.  An issue rolling over into the next sprint is indicative of a problem and should always be discussed at the end of the sprint to see how you can improve your process. 

The usual reasons an issue moves to the next sprint are poor estimation (a story should always be achievable in a single sprint), people not really doing Scrum because they haven't grasped it (like the person who gave you that poor advice) and unforeseeable loss of resource (sickness, outages, developers pulled out to help out with production incidents, etc).

[Shari Fitz-Patrick]

Thank you very much for this clarification.  I really appreciate it.  Thanks

[Alex Koxaras _Relational_]

Hi @Shari Fitz-Patrick 

First of all I would consider this question to be more Scrum related, rather than Atlassian/Jira related. From what I know having read the scrum guide, the scrum team decides what they will work on toward the sprint goal. The sprint goal may have a done increment of certain pieces of works.

If the scrum teams falls behind on their work, this is something to discuss on the retrospective. The work left behind is gong to the backlog and later on the team decides what to work on the following sprint.

So to me, there is no right or wrong. Move them to the next sprint.