Separating sub-tasks sprints from their parent task

[Idan Klein]

Hi all,

In my work we have tasks that are divided into small sub-tasks, and we work in a 1 week sprint. Sometimes a whole task takes more than one sprint, and the sub-tasks needs to be divided into different sprints (for example, for a certain task there are two sub-tasks, and they need to be done one after the other, not together, and the first one takes a whole sprint to do, so the second one should be done in the next sprint).

When I'm trying to edit the sprint of a sub-task, this option is disabled and it says "Inherited from parent.".

Is there a way to separate sub-tasks to different sprints? Or any other way of managing a case like the one described above (so I won't lose the connection between the two sub-tasks and their parent, but still be able to assign them to the developers on two different sprints).

Thank you in advance!

[Nic Brough -Adaptavist- · Accepted solution]

No.  Sub-tasks are part of their parent, not independent entities.  Having them in a different sprint to their parent is nonsense.  

What you're trying to do here completely misses the point of Scrum, and breaks it, you might as well throw away the concept of sprints and measuring your velocity.

You need to change the way you estimate and sprint.  A story (and hence all of its subtasks) should never be too large to fit into a sprint.  You could vary the size of your sprint, but you must not make it too long, or you lose the agility that scrum enables.  A better option is to improve your grooming - when you have a story that is looking too large to be done in a single sprint, split it up.

In your case, it sounds like the easiest option is to draw the subtasks out as stories themselves, as that's how they are sized, and then group them with an Epic, or with issue links.

[Michael Sanchez]

Your response allows for only one possibility for a sub-task to jump sprints - the failure to adhere to the basic principle that stories should not exceed the sprint - in time/size. Have you worked in the real world? You plan and size correctly, and then real work life hits and then "oh heavens what now?" you're not done with every story at sprint's end. Even the smallest of stories for lots of reasons are sometimes stopped in their tracks and must jump sprints. The same happens for sub tasks - no matter how carefully and comfortably it all fits when initially populating the Sprint Backlog.

You can respect scrum, total up actual velocity, track a sprint-jumping task or 2 to a parent story without having to drag the parent story with 6 subtasks into a new sprint with 5 of them immediately landing in the Done column. It doesn't even reflect velocity acurrately, since none of those 5 subtasks were actually completed in the new Sprint they were all forced to move to. Are you going to tell me now that velocity isn't scrum-y enough if it's allowed to count up complexity at task level, only story level? Again, one day in real life enlightens you to the fact that that's meaningless oficiousness, paradoxically as utterly vacuous as it is completely full of s***. As are virtually all defenses and justifications of Jira's utter stupidity and lameness.

[Nic Brough -Adaptavist-]

Yes, I've been part of Scrum teams for longer than the Agile manifesto or Atlassian have existed.

Please have another read of what I've said.  In real life, yes, an issue may not get done and hence jump sprints.  That is not what I've talked about, I've talked about how to do Scrum.

Scrum says nothing about sub-tasks.  They're just fragments of stories (and hence don't go into sprints, or have estimates).  Jira Software is a Scrum tool, and it does the basics.  If you're going to estimate on sub-tasks, that's fine (I quite like doing it myself, and I freely admit that I loved having people ask me to do it properly, got a whole load of timesheet entries for "writing scripts to do it well), but you need to build something that can make Jira understand how that works for your Scrum process.

TLDR: sub-tasks are not sprint items.  If you think they are, you are not doing scrum.

[Stephan Shere · Accepted solution]

As Nic Brough mentioned, it definitely does break the methodology, however, again, as mentioned by Nic, splitting the issues into their own stories and placing these into new sprints is the recommended way to go.

You can create a new Story from the task, or even a 'Fixes Story' with issues to be completed as tasks and link the second story to the first story using Related Issues.

Simply modify the sub-task into a story or task, link the issues, and move the story to the backlog.

This will give you a link from let's say Sprint 3 back to Sprint 2 while issues remain under their respective Sprint.

This will enable one developer to work on the the OLD stories while new developers can continue to work on new tasks.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

>In my opinion it would be a useful feature to allow subtasks to live in multiple sprints or iterations.

Nope.  That would make your process less Agile and certainly not Scrum.

There's no harm in working in different ways, of course, and if the concept of timeboxing (everything in scrum is a timebox, a sprint is just one) works for you, by all means do it.

But don't call it scrum, and don't expect scrum tools to support it!

[Nic Brough -Adaptavist-]

It does not seem like you read my statement very well, you missed all the stuff about sub-tasks being a part of their parent.

But I clearly failed to describe or delineate the tools properly.

• Jira is not a Scrum tool.  It is an issue tracker.
• Jira Software is a Scrum and a Kanban tool.

Your processes are not agile, so you don't have a lot of use for agile tools.  I think you need to stop pretending that you are doing Scrum, or even being Agile, your writing suggests that you are not.

There is a simple fix for your usage of an issue tracker - don't ask it to create projects aimed at agile working practices, just ask it to be an issue tracker.