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; } } }

Alternatives to putting subtasks in different sprints?

Arlene.Amaya

I would like to put subtasks in different sprints, but from what I've read, there's no way to do that. Wondering what alternatives there may be? Something I'm considering is inserting a fourth level to hierarchy (Epic, Task/Bug/Story, Subtasks), perhaps between Epic and Task/Bug/Story. Any considerations I should keep in mind or alternatives to that approach?

Accepted answers

All comments

Trudy P Claspill

Hello @Arlene.Amaya

Jira does not support adding an issue hierarchy level between Epic and the "standard" issues level.

Subtasks can't be added to sprints independently of their parent because they are not considered separate from their parents. The parent issue is the level at which sprint planning and velocity is measured. Issues at that level should be sized/scoped to be able to be completed within a sprint.

If the items that you currently have defined as subtasks need to be handled independently in Sprints then they will need to be converted to an issue type at the "standard" issues level (Story/Task/Bug). Or maybe you need to decompose the parent issues into more independent and smaller scoped issues and divide the original subtasks among them.

Tell us more about the problem you are trying to solve. Why do you think you need another level in the issue hierarchy? Maybe there is another way to address the problem.

Chase Flinn

The flaw in that logic is assuming the elements that make up a PBI will fit perfectly into a sprint. A story may start towards the end of the sprint and the QA work might want to be accounted for in another sprint. The story is the outcome we want to achieve and we do not want to horizontally separate the QA portion just to account for it being in the next sprint. The story is done when all the work is done.

You should enable the ability to move subtask to separate sprints from the parent.

Trudy P Claspill

@Chase Flinn

If the QA work (subtask) is required to be complete in order for the parent issue to be complete, then the parent issue also needs to carry over to the next sprint. I don't understand why you would need to move the subtask to another sprint without also moving the parent issue.

Nic Brough -Adaptavist-

Welcome to the Atlassian Community @Chase Flinn

I think you're missing the point of sprints here. They do not assume stories will always fit within a sprint, that is simply what you should be aiming for. Items carrying over into the next sprint means the team has failed to deliver what it said it would, and so needs to examine why it failed.

Sub-tasks are not sprint items, they are a fragment or a part of a story. If you have decided to create QA as a separate part of a story, that's fine, but it is nonsense to to put them into a sprint as anything other than part of a story you have not finished. Completion of a story is binary - it's done, or it is not. Not done includes having bits that are not complete (i.e sub-tasks)

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud