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

How do you plan subtasks into separate sprints?

Andrew Waites

We are currently using 6.01 and I cannot see subtasks on the planning board (not even on a tab on the task display panel as I believe I should) - regardless it appreas that at a planning level the expectation is that we should plan entire tasks into a single sprint (once in work mode I can see the subtasks).

Some of my problems are:

1. I would actually like to be able to schedule different subtasks into different sprints.

2. Once the parent task is in a sprint I do not know how to (or it seems I cannot) close some subtasks then get the parent and its remaining incomplete children into the next sprint.

So, either I have this all a^&* backwards and am trying to do the wrong thing or I am missing something fundamental for which I apologise.

At the moment the classic planning board is looking pretty good to me.

Any pointers as to how this is meant to work would be much appreciated.

thanks

Andrew

Accepted answers

sclowes

Hi Andrew,

You cannot add a sub task to a sprint without its parent story.

Are you not seeing the sub-tasks tab in the detail view on the plan mode of your board? You might need to send a screenshot because the tab should always be there and includes a 'Add Sub-Task' button. You can see what the tab looks like in a screenshot from the release notes.

Once you bring the parent task in to a sprint you will see its child sub tasks as addiitonal cards in the work mode. You can independently update the status of the subtasks. At the end of the sprint the incomplete story (with its complete subtasks) will automatically go back to the top of the backlog, you can then schedule the story for more work (to complete the incomplete subtasks) in a future sprint.

Thanks,
Shaun

All comments

sclowes

Hi Andrew,

You cannot add a sub task to a sprint without its parent story.

Thanks,
Shaun

Dean Berman

Shaun, I appreciate your help on this, but it definitely doesn't help him out, nor answer the question that had been brought up hundreds of times to the Greenhopper support...how to review subtasks in planning mode. I made this same request months ago and got the same answer~ish: It will never be added as an option, regardless of how many people have request it. Dean

sclowes

Sorry, he was asking if this was possible and it isn't. We have no plans to change this behaviour, a sub task cannot enter a sprint without its parent issue.

Thanks,
Shaun

Dean Berman

But why not have the ability to pick specific subtasks and move them in the sprint along with the parent task. Basically to add a parent task and only particular subtasks. Right now it assumes every single subtask with a parent. It would be helpful to add subtask A B E F I (and it's parent of course) in the sprint...and C D G H are not in the sprint...? Dean

steve laflen

can't your eng just pick the next story in the backlog to work on?

Jason67

I'm going to have my sub-tasks that are slated for the sprint be assigned to the engineer along w/ the parent leaving the Product Owner to own the sub-tasks not yet slotted to a sprint and then filter accordingly.

The issue for me is that while a story could be written granular enough to release at the end of the sprint, we know ahead of time that we wouldn't release (or even test) the story until various multi-sprint stories are done so we need a way to make it easy (ie, in a single ticket) for QA to find everything they need without linking and filtering all over.

Ryan Flores3

I can't understand why people would want a Story to be split across multiple Sprints. If a Story needs to be completed in multiple Sprints, it's no longer a Story, but an Epic. In these situations, change the Story into an Epic, then create new Stories under that Epic. You can then move the Sub-tasks that need to be completed in a later Sprint into the other Story/Stories and plan accordingly.

If you have Sub-tasks that are too tightly related and the summary of the Task/Story couldn't be rephrased into something meaningful if split apart, then it's possible you're Sprints are too short/aggressive. You may want to consider increasing the length of your Sprints, especially if this is a reoccuring problem.

If this is unclear, you may want to re-read the definition of Stories vs Epics.

Jose M_

If at a certain point we need to handle a sub-task independently from its parent, we need to convert it to an issue. Up to now sub-tasks are not handled in the way as issues in Epic, where the Epic may belong to different Sprints.

Lonnie Vanzandt

In my planning, I use Epics to represent aspects of a Product. For example, "Documentation", "Quality Assurance", "Core Capabilities", "Project Management". I use Components to represent modules of the software. For example, "User Interface", "Vendor Libraries", "Persistence Service", "License Manager".

I use Stories to express User and Stakeholder service expectations and the rationale for those. For example, "Story: Prospective Buyer can discover online links to Product XYZ" or "Story: Tester-as-Buyer can discover links to Product XYZ in Sandbox World". A Story is realized through the completion of Tasks over time, over time that easily spans Sprints.

I use Sprints as a workflow metronome that simply calls out the cadence and guides the team in working and delivering in a consistent repeatable manner. Like the call of the coxswain in crewing.

I use Versions to satisfy the Stakeholder: for each Sprint, we deliver whatever our workflow is producing while for a Version we make a conscious decision to attend to details, to bundle everything up, to deliver something sustaining and supportable. With a Version, we deliver something we expect the user will appreciate so much that they'll even pay us for access to it.

I use Task/Sub-task Issues to represent engineering activities that are relatively atomic and can be reasonably accomplished by an individual within a two-week Sprint. (This use of a Task matches very well with traditional JIRA issue management–and poorly with Agile JIRA for the reasons this thread elaborates.)

Several points are:

Epics never conclude. For, when is your team really done with Quality Assurance? Or with Project Management?
Stories truly serve to inform the team why capabilities are important. Pure Agile be damned: a good story is compelling across products, epics, versions, and tasks. Most real Stories do not end within a two-week Sprint.
Tasks are Specific, Measurable, Achievable, Realistic, Timebound and (in well-functioning teams in manageable environments) are usually accomplished by the right people as planned.
Sub-tasks are an effective way to manage complexity and difficulty and partition a large task so that multiple people can accomplish it and can do so contemporaneously yet not necessarily simultaneously.
Task and Sub-Task should be the same Class of things and simply be a relationship between Tasks. All accounting of effort and progress should automagically roll-up Subtask status to Tasks.
Story Points should be the sum of the Estimates of Tasks and their Subtasks.

Agile JIRA enables some of this methodology and stymies some of it. If Atlassian listens to the voice of its users rather than to the preaching of the purists, more teams could use Agile JIRA to suit their needs. Never deny your user the right to use your product as they deem appropriate. If they hang themselves or others, that's their fault. Sell them Professional Services to rescue them and set them on the Right path.

Michael Gallagh4

Thanks for this feedback. It opened my mind to another way of organising from Epic to Sub-tasks, and we have modified our process as such. Cheers! Mick

Karie Kelly1

What Atlassian also doesn't recognize is that scrum teams include in their sprint other activities from other organizations. Remember, if you want to only allow agile by the book, the sprint is to include what the team can pull in and complete in their defined sprint. The 'backlog' for a team is not always just software work (e.g. features and bugs); many times, those same teams support other organizations and we cannot dictate a process to these other organizations. Even Atlassian says that other orgs should be able to use it to track their projects/processes. Ah...so, they do. But, epic isn't a pm term. The parent/subtask feature is much more common and intuitive for such project management activities. So...they have a subtasks and it needs to be done by a team. The team wants to bring that into their sprint. However, they cannot because Atlassian is saying 'nope' – only stories and parent issue types. Scrum teams cannot bring into their sprint other issues that they are responsible for because the sw says "that not the way you are supposed to do agile".

In this case, the team is trying to make sure they include in their sprint all the activities that they need to do; but, the sw prevents it.

Again, why is Atlassian taking this fight one when there are many valid use cases that have been presented to them on why this would be helpful; the flexibility would benefit your clients' processes...not hinder them. Why, Atlassian, do you care so much about enforcing this limitation? You want other organizations to use your tools...but, you're making it difficult to do so. You're making it difficult for organizations that don't have processes exactly like yours to be successful and wanting to use your tools.

Please don't tell your customers that they are doing it wrong, they don't know what they want, and they don't know what they're doing. That's not best practice customer service and understanding.

Matthew Pilgrim

I too can't quite see why the requested flexibility has not been included. Despite how others think someone should arrange their work opinions will always differ and having a tool that supports you is important.

That said the main reason I had for using a story and sub-tasks was to make sure they were grouped. I'm now using the 'link' approach: https://confluence.atlassian.com/jiracoreserver071/linking-issues-802172687.html

Hope this helps.

Mithun Antony

Select the Sub-task -> Click on More -> Click convert to Issue -> Choose as Task/Bug -> Click next

The sub-task will be converted to Task/Bug which will be available in backlog and can be move to sprint board

Simon Greenwold

This isn't "solved." Atlassian is intentionally making it impossible. Our organization mandates the granularity at which we use epics. Therefore stories and subtasks are the only units with which we have any flexibility. When we fill a sprint with work, we commonly have room for a little more of another story. Why not let us include some subtasks from another sprint? It seems like a religious choice not to. I would prefer my software not to hamper obvious beneficial workflows.

Siddharth Srinivasan

I use Sprints as a workflow metronome that simply calls out the cadence and guides the team in working and delivering in a consistent repeatable manner

What do you put in your Sprints, if you use Tasks and Subtasks for product features, and Epics as ongoing streams? The main issue here is that Subtasks cannot be put in a Sprint, so basically you can only have Tasks that finish within a Sprint, rendering Subtasks useless to us, at least.

Nic Brough -Adaptavist-

A sub-task is simply a way for developers to think of fragments of a story. The whole planning, provisioning and estimation stuff is done a level above.

Sub-tasks are not for planning and estimates when you're doing Scrum, they're just there to allow your "developers" to represent how they want to divide up work.

athenot

This is useful for release management. When the final step of deployment is a release to production and you have many independant production environments that follow different schedules, this would be very useful.

As of now we hack it with epics and scripts to auto-generate tickets but it looks like switching away from Jira will be our best bet.

Nic Brough -Adaptavist-

That sounds like a broken usage to me.

Why are you including deployment in your sprints? That's something that should be handled completely outside sprints.

Lukas von Blarer

This makes sprint planning with user stories and subtasks basically unusable. Atlassian, please reconsider this decision...

Siddharth Srinivasan

While I agree Atlassian is being stupid and pedantic with this whole subtasks issue, the best way to think about it is that Sprints and Subtasks are incompatible. If you want to use Sprints, forget about subtasks, and use Epics + Issues in Epics instead. they serve the same purpose, and are in fact more flexible since you are not limited to the same project.

Nic Brough -Adaptavist-

It's not "stupid and pedantic", splitting sub-tasks across sprints makes a nonsense of the numbers, is complex to handle, hard for humans to grasp, and in real life, does not work.

I'd suggest you have a read through the conversation above properly instead, look at the reasons it does not work, and then look again at what you're trying to do and why. You should find you are making a mistake somewhere.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

sprint

sub-task