Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How can I add Subtask to a Sprint?

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?

23 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

64 votes
Answer accepted

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.

I can only agree with you.

Like Marek Pałyga likes this

this is ridiculous...

Like Pankaj Yadav likes this

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.

another frustrated user

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

Really wish Atlassian to hear the voice of customer 

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.  

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.

Another upvote for fixing this.

Please fix this.

3 votes
Deleted user Sep 15, 2017

Another vote to fix this.

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.

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

/Francois, frustrated user

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

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

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

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

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.

Another vote for fixing this issue

Another vote for getting this issue fixed.

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

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

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.

most frustrated user.

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

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

1 vote
Janet Albion Atlassian Team Jan 08, 2013

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 ?


Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question


Atlassian Community Events