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.

[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.