How do you plan subtasks into separate sprints?

[Andrew Waites]

Hi

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

[sclowes · Accepted solution]

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

[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

[Andrew Waites]

Shaun

Thanks for the response - yes I can see the subtasks - user error on that front

Sorry to start a skirmish. This will work for us, possibly not ideal but functional.

thanks

[Ashton Treadway]

Shaun:

Here's a use case that we're running into. We have a parent issue A, with sub-tasks 1, 2, 3 4 and 5, all of which have time estimates.

Altogether, the sub-tasks add up to more time than the team has in this sprint, but they can fit in sub-tasks 4 and 5.

They want, and I think this is reasonable, to be able to split sub-tasks of a master task across sprints: in this sprint, we can do 1, 2 and 3, in that one we can do 4 and 5.

How do I give this to them?

[EddieW]

Subtasks can be viewed by showing a story in the sidebar. I think this aligns very well to the concept of stories in an agile methodology, particularly scrum boards. A story is done when it is done, and should be doable in a single sprint. If not you should try to separate the story into more granular efforts. FOr those that you asbolutely feel cannot be more granular and still capture the intent it sounds more like an epic then a story. Epics can cross sprints, and will show the assigned stories in planning mode.

[sclowes]

Hi Ashton,

This is really common in Scrum, effectively the story simply cannot be delivered in one sprint. The most common way forward is to split the story, that is, write a new story (that still delivers customer value) that is smaller, then take the applicable sub tasks to the new story. In JIRA you can do this using the Clone issue functionality, we hope to make this easier in the future.

Thanks,
Shaun

[Ashton Treadway]

Shaun:

There is an additional problem with this entire approach: the Rapid Board issue count doesn't match up with the issue count of its own underlying filter, because it's not counting sub-tasks. Rapid Board shows 105 issues, underlying filter shows 170. The difference is the sub-tasks which aren't being counted.

This is confusing for our users, a significant annoyance, and further underscores that you are doing the wrong thing here. I understand purity of purpose as well as anyone, but, for God's sake, you've got threads full of people telling you that the way you're doing this doesn't make any sense for how people are ACTUALLY WORKING.

The way you are doing this is arbitrary, poorly thought-out, and you are sticking to your guns in the face of customers who are telling you that you're actively alienating them. You need to rethink.

Atlassian's stock in my company is already significantly damaged. Over the past year, I've been killing myself trying to rebuild trust in JIRA. You are doing me no favors with this kind of head-in-the-sand WE AIN'T CHANGIN' NOTHIN' attitude.

I have next to no hope that you will actually pay attention to what I'm saying, but I'm far from the only person saying it, and I would really appreciate it, personally, if you could stop embarrassing me when I try to tell people that JIRA really is a product they can trust.

[Ashton Treadway]

Shaun:

So it's clear what we're trying to do:

The dev team does not use Greenhopper. When they build a new feature, they file a "Feature Request" ticket, then create subtasks for each part of the new feature. At least one of the subtasks is for documentation, and they assign that subtask to a tech writer.

Right now the documentation subtask doesn't show up in our rapid board. We want that subtask, and only that subtask, to show up in our rapid board. (The parent ticket isn't on our rapid board at all, and putting it there wouldn't make sense.)

Please point out to me the exact part of this that is outrageous, difficult, or somehow incomprehensible to the powers that be at Atlassian, because I've been doing Scrum since 2003 and don't see a problem with it.

Right now, in my company, we are using Greenhopper despite its flaws. It would be nice to use it because of its strengths.

[sclowes]

Hi Ashton,

I'm sorry this is inconvenient for you, we're not trying to be obstructionist. Unfortunately doing it this way has so far been the most appropriate and understandable way for most users. I'm sorry that trust has been lost in JIRA, you don't cover why that trust has been lost, but I can honestly say that the GreenHopper team is relentlessly focused on delivering the best Agile planning tool on the planet. We've have over 20 releases in the last year and we plan to continue delivering every two weeks.

In your particular case I can think of a few options:

• Have the documentation tasks be normal issues and link them to the 'Feature Request' ticket
• Use a Kanban board for your documentation tasks
• Have 'Documentation' be a state in the workflow of the Feature Request ticket and have your documentation board use that state as its first column, the ticket can then be planned in to a Documentation sprint when it reaches that point in the workflow

Thanks,
Shaun

[Ashton Treadway]

Why on earth are you guys choosing this as a hill to die on?

You are getting consistent feedback that people want one of two options: either the ability to put sub-tasks on the Planning Board, or for Kanban to have a Plan feature.

And your responses basically boil down to "you don't want what you're asking for, what you really should be doing is X". This is, to say the least, counterproductive.

[Michael Nyman]

Every time I want to do something obvious and can't figure it out I go to google, search and see the same thing: a ton of people in the same boat and a response from Atlassian saying "that's not the way to do it. We have no plans to do the obvious. Do it our way." This is *exactly* why I told our company to no longer give you any money. I wish everybody else would do the same thing. P.S. the wacky text and slanted page thing is HORRIFIC. I guess you don't care about legibility either?

[steve laflen]

Yep, just support it Atlassian guys. Your customers are paying a lot of money for this solution. Your basing decision on a rigid approach. Truth is that many teams use hybrid approaches based on Agile but are not 'pure' agile. The team at the end of the day decides how they will deliver customer solutions and the tool cannot, and should not, dictate how solutions are delivered. surprised that there is not some sort of 'custom' board solution you'd provide. Maybe there's an upsell add-on or something we're all missing.

[Deleted user]

I too agree on the fact subtasks should be individualy planable across different sprints.

Greenhopper does a good job providing SCRUM functionality, though it should leave it up to the user how to implement their SCRUM organisation. When an abundant amount of users give notice about planning subtasks across different sprints, in any case give them the option to configure it that way. I do not see any technical reason why not to (and the functional reason should be left to the users).

I do hope you reconsider this point in a way you can satisfy all users which do and do not want to plan subtasks in seperate sprints.

[Roei]

Hi Shaun,

I have to agree with everyone's request to plan sub-tasks freely, why not give users the extra flexibility when there is a big community out there asking for it.

But I have another question, what if an Epic has sub-tasks, how do I plan those on the board? or is it not possible to plan Epic's sub-tasks without having the layer of user story in between?

[Andrew Cohen]

I agree with everyone that sub-tasks need to be able to be planned into separate sprints.

[George Barker]

Happy New Year everyone. I now have to take about 100 user stories and make them Epics, and maybe 300 sub-tasks and make them User Stories. Except they aren't user stories...so what I really have to do is completely rewrite basically everything. Thank you Jira.

I will say this: If you don't want people using sub-tasks this way how about making that a little more clear in the UI? This whole thing is extremely aggravating and your answer of "you're doing your job wrong" is just pissing everyone off...

Since I have to now rewrite everything anyway I might as well have a look at some competing solutions...

[George Barker]

And another thing: Say I've got my 2 week sprint 90% full. There is no way another full user story will fit into it. I could easily add a few sub-tasks of another user story to fill it out. But you're telling me no??? I should come up with some bs user story just to adjust the sizing to fit the odd lot of my sprint plan? Or should I tell my developers to book some vacation time since Jira doesn't let me break a user story across 2 sprints?

[Deleted user]

As a JIRA Agile user, and a Scrum Master, I wholly suppport the approach Atlassian has currently taken for planning stories and sub-tasks in a sprint.

The fact that sub-tasks of a story cannot be added to multiple sprints encourages proper behavior from "agile" teams. It also helps "not-so-agile" teams realize that the whole point of Scrum is to deliver a completely functional feature at the end of a short iteration.

Teams who do not understand this basic principle of Scrum should not blame the product for doing something well. They should, instead, focus on improving their internal development process or at least try to learn the basic principles of Agile.

JIRA does not force you to use Agile. You can use JIRA to develop in a completely waterfall manner if you so wish. But for God's sake, do not try to change an Agile tool to do waterfall.

I'd like @AshtonT. to give me some examples of Stories and Sub-Tasks that he would like to schedule in different sprints. I'm confident that Ashton's stories are probably Epics and his sub-tasks are probably stories.

If they are indeed big stories that can span multiple sprints, they should be broken down into two or more stories. Agile allows one to break bigger items into smaller bite-sized chunks that can and should be completed in one sprint.

There's a common theme in most of these threads and it signifies that some JIRA Agile users do not really understand the concept of Agile. They do not know what Epics, Stories and Sub-Tasks really represent.

Instead of trying to change the product, and instead of implementing one's own "Agile", one should first try to understand what Agile is all about and what parts of it are integral to getting any value out of it. Disguising waterfall as Agile does not provide much value.

[Elizabeth Cambridge]

Thank you Shaun, your solution worked like a charm.

[Lauren González]

Hi there. @jhabib, if you take a look to JIRA Agile's promotional video on Youtube, it encourages using it for everything from software development to project management, sales, customer care, etc.

@Shaunand you are just telling the oppossite. I love the Agile approach to everything, but it needs further flexibility. It's not a matter of whether sub-tasks can be planned or not, it's just a hierarchy problem. Going up to project management level, the three level hierarchy (version->epic->story) is simply not enough for the complexity, so we have to use versions as epics, epics as stories, and stories as.. sub-stories?.

Name it as you like, we are just asking for deeper hierarchy for complex non-just-software projects. Maybe we actually don't want Scrum at all, but we love Scrum planning board for complex project tracking and with individual sub-task planning ability it seems fair enough.

If you keep on saying this is not the way to go, then the speacher on the video promoting "agile-for-all" with Greenhoper in Atlassian is cheating us. And I think he's not, I think he's right and Greenhoer is just not listening to him.

[Deleted user]

Hi @Constantino, I'm glad that we're having this conversation and hope that the product can be imporved.

I will provide you an example below that, I believe, can be used to express any complex project or product development.

Product/Project - JIRA Object

• Super Awesome Car (SAC) - Project Category
• SAC GT Edition - Project
• SAC GT 2012 - Version
• SAC GT 2012 Suspension - Component or you can use Epic

You can then have stories in the epic for Suspension for Development, Tuning, Testing and even have sub-tasks for each story. Or you can represent Suspension as a Component and then use Epics for Development, Tuning, Testing.

So, essentially, you have the following structure in JIRA:

Project Category>Project>Version>Epic>Story/Task/Bug/OtherIssueType>Sub-Tasks.

Components and Labels provide dimensions to the structure above.

Can you please give me an example of a hierarchy (using fictional or real product/project names) that you cannot currently express with the hirerchy described above?

[Lauren González]

Hi @jhabib. Using components is for sure a way to go. I'm not so sure about Project Categories, would prefer to have everything inside teh project scope.

Problem still is something about hierarchy. You cannot enforce component usage as part of a hierarchy (i.e, components per version). On the other part, some of our stories do actually have **stages**. Not about waterfall, it's just dependent tasks. We could group them on epics, but again we loose one level.

Don't you like that nice progress bar below the epics and versions telling you how close you are? I just want that for stories with several sub-tasks that we know for sure they don't fit in a sprint but need them to be tied to a story.

It's not that we can't figure out a way of organizing issues (we were using parent/child links before Agile), it's just that having a full hierarchy view such as that provided in the Scrum planning board is absolutely great.

Maybe we just need to migrate to this for project management, but I still like Greenhopper/Agile better, and the work board is so nice to work with: https://marketplace.atlassian.com/plugins/com.almworks.jira.structure

[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 Gallagher]

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

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

[Siddharth Srinivasan]

That makes sense. What does not make sense is this arbitrary layer called Epics, that work differently than regular tickets. For example

• closing an Epic ticket does not close the Epic, you need to do that in a different view (https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-epics/completing-an-epic). Why? An Epic should be like any other ticket: close it, its done.
• Naming an Epic is a chore. Its different than the ticket title (https://confluence.atlassian.com/jirakb/unlabeled-epics-779158637.html). Why? Why have a specific process to name an Epic that is a completely different process to a normal ticket workflow?

I agree with your understanding of Sub-tasks, and can live with it (though I still feel this is an arbitrary distinction). But this special treatment of Epics is annoying as hell.

[Nic Brough -Adaptavist-]

Epics are totally different objects to stories and issues, hence the different interface.

I sort of agree with the summary/name difference, but it's evolved of necessity - quite often, Epics are converted from stories, where a summary would not be good enough to describe the overall arc of the Epic involved.  But you want that summary because it's useful for the actual story that was raised.   In real life, it is clear that people are unlikely to use the summary as the name of the Epic, hence the separate field.

The separate field also makes coding a heck of a lot easier...

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

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

[Karie Kelly]

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.  

[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

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

[Ryan Flores]

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.

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

[Jason]

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.

[steve laflen]

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