nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can Sub-tasks be added to a sprint individually?

Hitesh_ym5avq

Hello,

I have multiple issue which contain around 13-14 sub-tasks linked to them. I know for a fact that when we add a parent task into a sprint the child will get tagged with the same sprint. But i wanted to know if there is a way to have these sub-tasks be added into a sprints individually.

My use case: Lets say along with the parent task only 4-5 sub-tasks can go into first sprint we want to add the rest to another one.

Please advice.

Thanks!!

Accepted answers

Trudy P Claspill

Hello @Hitesh

No, subtasks cannot be added to a Sprint independently from their parent issue.

With the scrum methodology the idea is that a task/story is scoped such that it can be completed within a single sprint. And subtasks describe the work required to complete that parent issue.

If the task is too large to be completed within a sprint then it should be split into two tasks; each of which can be completed within a sprint.

Otherwise you will have to add the parent task to one Sprint, complete as many of the subtasks as you can, and then roll the task into another sprint during which you can complete the remaining subtasks.

All comments

Trudy P Claspill

Hello @Hitesh

No, subtasks cannot be added to a Sprint independently from their parent issue.

With the scrum methodology the idea is that a task/story is scoped such that it can be completed within a single sprint. And subtasks describe the work required to complete that parent issue.

If the task is too large to be completed within a sprint then it should be split into two tasks; each of which can be completed within a sprint.

Pasam Venkateshwarrao

Hi @Hitesh

You can't do this at all. Sub-tasks are part of their parent, and hence not even considered to be part of a sprint. They go with their stories into a sprint, all together because they are a part of their parent.

The concept of having sub-tasks in different sprints is simply wrong. The parent goes into a sprint and, because the sub-tasks are part of it, they go with it.

If you are regularly finding you are partially completing a story and hence rolling it into the next sprint (with its component sub-tasks), then you either need to improve your estimates and sprint selection, so that you don't commit to too much work, or improve your story writing, breaking up your stories more, so that you can commit to the right amount of work by only taking in what you can do.

unknown

That is just a duplication of the same answer that @Trudy P Claspill provided, 3 hours ago

Hitesh_ym5avq

Thanks Trudy,

Thought so, just wanted to be sure.

Martina Schlager

I’m curious whether there’s an actual technical reason for that rule, or if it’s just strict adherence to a methodology that none of my teams have ever managed to follow 100%, no matter how hard we tried.

I’ve been doing this since the days when the methodology was still called x-programming and Jira was Redmine—so I’ve been around for a while; please don’t mansplain it to me.

There are countless situations where organizing subtasks across multiple sprints is genuinely useful, and it already happens today through plenty of clumsy workarounds. Why not let users decide how best to use the tool?

Why am I using this approach, nonetheless? Because the subtask view—with task status, estimated time, and time used—is simply the best overview in all of Jira.

My two cents,
M

Antun Bartonicek

I completely agree with this.

Having this (unable to pull sub-task without a parent into a sprint) technically enforced is the only wrong thing here and users should be able to use the tool or "violate" the methodology how they see fit.

Martina Schlager

Thank you!

I am managing multiple projects with varying sprint durations, and it is often simply impossible to complete all subtasks within a single sprint.

I hope that with the new “parent” methodology, this very frustrating limitation will be resolved.

Thanks,
M

Antun Bartonicek

Same problem here but the "then story is too large and should be split" people don't understand that the story doesn't have to be too large for one sprint it is just too "large" for available resources for next sprint.

Imagine basic sub-tasks: DEV and QA.

If QA resources are not available for next sprint it just means that we shouldn't pick up the Story at all, even if we have enough dev resources to do the dev sub-task.

Then when the next sprint comes and we don't have enough dev resources we again shouldn't pick up the Story, so this is 2nd sprint where the Story was skipped.

So, either deliver it in 2 sprints and have reporting in red as we had "overcommitted" QA work and the story had to rollover to next sprint or wait until all the stars align to have all the resources available and deliver it in a single sprint

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-data-center

data-center