How can I add Subtask to a Sprint?

[Joe Patel]

We created a task that had several subtasks. It's not possible to finish the entire task in a short time so we would like to plan several sprints to complete this task. But in my planning board, I can only see main issues, not sub task issues. The advantage we have with subtask is that we can update time against the subtask and it will update the total time in the main task which helps us with time planning. Separating the subtasks into other tasks would leave us no way to do that so we can't really use main issues for these items. How can we solve this?

[Guido Wilken · Accepted solution]

Hi, this questions pops up all over the place and I don't really understand, why it has been implemented in Greenhopper 5 and when talking about Greenhopper 6 it seems to be the devil himself when it comes to SCRUM.

People acutally work that way and for us this is as well a no-go for Greenhopper 6.

Our tasks, that deliver the business value very often consist of a lot of subtasks for different subsystems of the project, as functionality spans over various aspects. When we define such a user story (=task) we usually define all subtasks already and try to estimate these to get a good feeling on the total duration. This is often longer than a sprint and I already hear you saying "break down the task", but as told before, many times, this is not desirable, since creating smaller tasks that don't deliver the desired functionality in itself and grouping them by epics or links makes it harder to track such a feature and closing smaller "New Feature" tasks, that acutally don't deliver a feature would clutter our reporting.

Even worse, we're not able to do the sprint planning with the new planning board, as a feature which holds a lot of estimated subtasks will on it's own exceed the time for the sprint.
Thus we usually plan only a couple of subtasks. It wouldn't be very helpful (as suggested on another thread) to let such an issue "travel" through on sprint after the other...

Anyway, I don't expect Atlassian to reconsider it's decision regarding the subtasks, but just wanted to let you know, that this way we are not going to move forward to GH6 and thus won't upgrade our maintenance as well... Another customer lost.

[Jean-David Dessaint]

I can only agree with you.

[Sumit Kumar]

this is ridiculous...

[Matt Ihnen]

Another vote for fixing this, I was shocked when I found out I couldn't do this. Will consider cancelling our subscription and looking at other options just because of the lack of this feature.

[moritz löser]

another frustrated user

[Luke Deniston]

This is bad and Atlassian should feel bad for doing this. I've read the canned response from them about you should use storys or something something story points but when I go to break up a large task into smaller ones so I can accurately predict and measure the results I would expect the paid scheduling tool I use to be accomodating.

Rigid != Agile

[Andy]

Really wish Atlassian to hear the voice of customer 

[Ronny Matthies]

We organize the development of bigger functionalities using epics, which we break down to stories for single features. As we are developing mobile applications in two specialized teams, we cannot always ensure to have one feature being developed in the same sprint by both teams, which is why we would have loved to use sub-tasks that could be put in different sprints but we can´t. I´m a big fan of JIRA but, sorry Atlasian, this decision really sucks.  

[Andrew Powell]

Extremely frustrating. This functionality was possible with Classic Boards. Can't understand why Atlassian have removed it! It is a massive retrograde step. Atlassian clearly don't understand how many of their customers work.

[Richard Sassoon]

Another upvote for fixing this.

[Simon Greenwold]

Please fix this.

[Deleted user]

Another vote to fix this.

[Jess Puplett]

We managed to get around this by adding an extra label indicating whether the sub tasks should be included in the sprint or not, and adding a custom filter to the sprint board using this label. Only the sub tasks we want now show up and the estimated time only includes the correct sub tasks.

[Francois Herrault]

I really wished you changed your mind on this matter. Making it configurable would be best.

/Francois, frustrated user

[Beatriz Beatriz]

Totally agree, doesn't make sense that subtask cannot be included. This is decision of dev team, not Atlassian team.

[Martin Gregory]

What is the difference between "The dev team" and "The Atlassian team"? Who's running the show? Isn't Atlassian "The Product Owner"?

[Fabian Valencia]

"The dev team" as the team using the tool built by "The Atlassian team". Should the customer own the product as a community? 

[Martin Gregory]

@Fabian Valencia I'm not clear on your point.   @Beatriz Beatriz seemed to be saying that there is a "development team" that has decided that subtasks cannot be added to sprints, separate from the Atlassian Team.   However, this feature is an Atlassian feature.  So how can there be a separate "dev team" that made this feature decision?

I don't think Beatriz was referring to customers/users.

[Steven Larsen]

Another vote for this "functionality". Thought the whole point of agile was the ability to work the way its best for the team/project and not be restricted to a specific approach. Come now Atlassian. I need the ability for clients to see a larger task being worked on, but not the entire thing.

For example, we use Epics to define the functionality the client wishes to achieve. We use Stories within the Epic to define the various sub-component uses (customer, system, admin, etc) for their specific experience/functionality, and we use sub-tasks to define the efforts within each of these stories. The stories collectively in the Epic can be lengthy (a few months or longer to complete) and each story can be lengthy (a few weeks or more). Our sprints are a week at a time generally and we'd like to be able to put the tasks within a story into a sprint so that the client can see the portion that is being worked and we can properly track the story as a whole.  But... my hands are tied without the ability to see to the level of a sub-task.  Sometimes the customer knows better given the real-world experience.

[Big Jim]

Another vote for fixing this issue

[Christian Uldall Pedersen]

Another vote for getting this issue fixed.

[Diccon]

Another vote for this feature - extremely frustrating not to be able to do this.

[Olic Moon]

So, this issue has been there since 3 years ago but still not fixed. 

[Jeff Bilbro]

Ditto - trying to use Jira Agile to manage sprints for my small Infrastructure team. Would like to be able to move subtasks forward without the entire task and all sub tasks.

[Venu Madhav]

most frustrated user.

[Martin Gregory]

I find it astonishing that this isn't possible, for exactly the reason Guido says.

[Jesse]

We have the same workflow as Guido Wilken. I am disappointed that this is not possible. It makes this plugin almost unusable.

[Janet Albion]

Hi Joe,

The Scrum board does not include the Subtask in the Plan mode and there is no plan to implement this at the moment. For detail view of the Subtask, the Work mode can be use.

Does the Structure plugin from ALMWorks for you ?

-Janet