It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to show the subtasks in the backlog/sprint tree?

I just started my trial period and I find doing the most simplest things very hard (or counter-intuitive).


For example, I want to see the child tasks of a certain task from backlog or sprint and I wasted more than an hour trying to configure it.

So, I would appreciate if anyone can tell me how to do that.


Thank You.

P.S. In the last 30 min I have seen so many times the "Sorry, we had some technical problems during your last operation" error, that I am kind of afraid to click the buttons... is the trial a beta or untested product?



8 answers

Funny i encountered the same request today....and was looking for a veryfing answer in the community, however i can't find that...which is a bummer because the thing is, i think it depends on the type of board you use. And before anyone starts rambling and posing their opinion this what i found and encountered.

Team One uses a Scrum board in Jira and it doesnot show the sub-tasks in the backlog view, just the parent. Perfect nothing wrong there...


Team Two uses an Kanban board in Jira and it DOES show the sub-tasks in the backlog view. It features this little hook, when you click on it the subtasks are shown.......


So if the functionality is in there for Kanban why not for Scrum??

Because in my opinion this is usefull!

I agree that it would help. At least as a reducible drop down.

Like # people like this

The thing that is funny to me about this whole thing is that they actually provide this feature with seeing subtasks on the planning board through their Kanban board.  So Atlassian thinks it is important enough to have it there but not important enough to have it on the scrum board.

You have been asking why it is important to have.  I'll give you that answer.  It allows you to prioritize the sub-tasks within a task.  It doesn't allow you to prioritize a subtask above another task.  So that argument doesn't even hold water.  The feature is there.  Why can't you apply it to your whole system rather than half of it.

totally agree.

Like Phyllis Chang likes this



As for the latest jira software version, although its not possible to see subtasks on the backlog as an independent line (and, agreeing with @Nic Brough, you shouldn't be prioritizing subtasks as independent items), it IS POSSIBLE to list subtasks of a given issue, and that may help to prioritize the issue, based on subtasks count, for example. It's a matter of adding the field to the backlog view:

  1. image.png
  2. image.png
  3. image.png

This way, on your backlog view, you should see subtasks this way:

Thanks Rodrigo, for your response. Rewording my question:

I have a story S with 3 sub-tasks T1,T2 and T3. T1,T2 are associated to a component API. S is to be completed in Sprint 1. I have not started Sprint 1 yet. 

I defined my board as based on the query : component = API

I expected to see : S with T1 and T2 displayed for the current sprint. But that does not happen. None of S,T1 and T2 are displayd

nic Community Leader Jun 21, 2017

Have you added the field to the card layout?

Hi Lakshmi,

Try to run the same filter used on your board at "Search for issues" screen. Can you see your issues and subtasks there?

This was just what I needed. Thanks.

Thank you Rodrigo Silva, your suggestion worked, and saved my time. Thanks Lakshmi for asking this question.

>You shouldn't be prioritising subtasks as independent items


No, no, no!


You cannot make assumptions about how Jira is and should be used; this is one of the main issues with Atlassian, as they try to force you to use their product according to their specific vision of project management.

A subtask can be as significant, or as insignificant as one chooses it to be, and should therefore be included in the backlog board if one so chooses.

Like # people like this

Thank you for this alternative!

I'm not seeing a an field option for Sub-Tasks. Am I missing something or does this need to be coded?

@Nic Brough [Adaptavist]  I am trying a slightly different situation - I have a story which is being worked on by multiple roles in my team ( a UI designer, an API developer, an Android developer etc). I have one or more sub-tasks for each of these teams in my story. I used component to identify whom the subtask was meant for. I would have liked to have a board which shows each team what the status of each sub-task was. What is the best way to do it

I think the best approach here would be to add query swimlanes to a board, based on components. Something like this:

The board will then look like this:

It should be noted that subtasks belonging to more than one component will be showed on the board on the top configured swimlane.

It should be also noted that the board filter must include issues of the required subtask issue type .

Like # people like this
0 votes
nic Community Leader Jan 31, 2016

You can't. 

The logic is quite simple - there's no need to see sub-tasks in the backlog.  You prioritise (i.e. shift the backlog around) at a story level.  By definition, if you have subtasks on a lower priority story, they cannot be more important than the subtasks on a higher level story.  As you don't need to prioritise subtasks at that level, showing them in the backlog is just noise, so the board doesn't bother.  (You can re-order them on the story)

On the technical error, no, a trial is the full version, and Atlassian keep it right up to date.  It is a form of beta or test-bed in some ways - Cloud gets regular deployments of the latest code every few weeks.  But it's tested code that Atlassian have a lot of confidence in.  If you continue to get these errors, I'd log it with support though, as getting them repeatedly is an indication of a failure on the server, and they need to look at those whether it's a trial or not.

@Nic Brough [Adaptavist]

"showing them in the backlog is just noise" - it is not noise because by default will be collapsed under the story.

"there's no need to see sub-tasks in the backlog" - there are people that check the backlog/sprints (upper management, customers that are billed based on that stories, etc); they see an estimate for a story and it seems to much (or too little); seeing just under the subtasks helps; (or maybe the story was badly split into subtasks, etc.) Just seeing them there is very useful.


Or maybe it is the wrong place to see that; it there another place where I can see the entire Epics -> stories/tasks -> subtasks tree?

nic Community Leader Jan 31, 2016

I don't think a backlog view of a story is the right place to be re-estimating stories.  The backlog view is for prioritisation and planning a sprint.  If a story is the wrong size, then you'd normally go into it so you can re-size it based on all the information on it.  A summary, even with a pile of sub-tasks, doesn't usually tell you enough to re-size it.

The second point is much the same as the first.  If you need the detail, you probably need all of it.  The backlog is for planning, not micromanagement, billing or the other stuff that probab;y means you should be looking at the issue.

The short answer is that you simply don't need sub-tasks on the backlog.


Not being able to show tasks in the backlog view, even as a customizable option, is a big issue. The argument @Nic Brough [Adaptavist] makes – "there's no need to see sub-tasks in the view" is too far-reaching. It's like saying "there's no need for you to have orange juice".

The way I manage my sprints depends on me being able to see all my subtasks in the backlog in a list, and there's nothing inherently incorrect about it.

That reason is simple to understand as well – I may have a story that that spans multiple sprints and I want to decide which tasks to pull into a sprint. Now you may not think that that is a good way to manage stories, but I've collected enough data to show that it does. Presently there isn't a view that contains all my stories and it's subtasks (backlog + current sprint). The "backlog" view, a misnomer since it contains the sprint as well, comes close but doesn't contain subtasks.

A view is a view, a collection of objects on the screen that makes it convenient for a user to manage data, and ultimately decisions, on a screen. You and I can differ on what that is, but Atlassian needs to recognize that here instead of imposing what it thinks is the best way for me to manage sprints.

Like # people like this
nic Community Leader Aug 08, 2016

You don't really explain why your subtasks are apparently so important.  To reuse your analogy, I'm not saying "there's no need for you to have orange juice", I'm saying that when you are looking at a backlog, and you decide you want some orange juice, you are then trying to rank that as more  or less important than desires for apple juice, milk, tea or beer.  In that view, the sub-tasks of getting oranges, juicing them, getting a glass, etc are really not relevant.

What it sounds like you have done here is got your Epic/story/subtask breakdowns done at the wrong levels.  "Story that spans multiple sprints" is a red flag for a start, and a desire to micromanage sub-tasks when their order is utterly irrelevant to a backlog is a strong indicator that something is wrong.

I don't need to explain why my subtasks are so important to me. They're important because I think they're important. You made the assertion that "there's no need to see sub-tasks in the view", which is a personal opinion at the end of the day. There is a need to see subtasks for a story and I can do that by opening the story up itself. I prefer not to do that and have my tasks listed below the story in the "Backlog" view. You may not like it, but that's your opinion, i.e., your "view".

When you assert "... have done here is got your Epic/story/subtask breakdowns done at the wrong levels", you are making the assumption about the way I run my sprints. As I said earlier, you may think that it's not a good way to manage stories, but the data I've collected shows that it is. It doesn't matter what you think ought to be better. I have a counterexample to show you're wrong. 

"A strong indicator" is just that – an indicator. Not a hard rule.

Like Wiz White likes this
nic Community Leader Aug 09, 2016

I understand that it's an opinion, but I still cannot see any value in seeing the subtasks.  If you would explain how they are useful to you, I might, but until I see that, I can only assume that you're doing your estimation/ranking at the wrong levels.

It's fine if you can't see any value in my approach, but it's not fine you to claim that there can't be any value at all for the OP or anyone other than yourself.  

nic Community Leader Aug 09, 2016

So demonstrate some.  My imagination may well be limited and I simply can't work out any real use for it, and that's why I say what I do.  If someone could show me a useful case, I'd accept it.  No-one has yet - they're usually not understanding the backlog evaluation process.

I don't know why they just don't have the option. It's ridiculous. It would not be hard to implement and then everyone can work in they way that they want to and find most efficient.

nic Community Leader Feb 06, 2017

Because it's extra code for no benefit, all that happens is you get people asking why they can't rank the subtasks, and complaints that there's too much on-screen that doesn't do anything.

I don't want to rank them; i simply want to see the story and their sub tasks (as you can in the detail pane if you click on the parent) in the main backlog view. I don't want the ability to re-order or separate or any of that; i just want a collapsible list so I can see everything right there.


Like Gerri Mills likes this
nic Community Leader Feb 07, 2017

I know, but how are you going to handle all the people asking why they can't rank them or get rid of the unneccesary clutter they cause?


First off, writing off a feature request because it generates complicated questions is a terrible rationalization to not implement it. Those complicated questions are independent, potentially worthy or necessary questions that when addressed ought either to make the product better or, at the very least, inform Atlassian of their choices.

Speaking more directly, since the proposal is to have an option to make subtasks viewable, they won't cause clutter when turned off. 

I know this has been discussed many times and the response has always been that sub-tasks are not part of planning, therefore not needed. We are trying to manage more then just development in the stories. We are including UX, development and test. I know this may not sound appropriate, but I'm not sure I'm that far off according to Dean Barker, Director of User Experience at Optum (see article). As Andy K mentions, shouldn't the user determine what is noise? It seems that managing tasks and resources (ux, dev, test)  that represent a story would defintely be part of planning. How would you suggest (besides links) that you organize the different tasks of a story?

Like Gerri Mills likes this

One reason you haven't considered is that when the sub-tasks are displayed you can easily drag them into Versions. And yes, I know you are going to say that sub-tasks should be in the same version as the story. Agreed.  But if you use the JIRA roadmap gadget to see how you are tracking, you want to see how many tasks overall still need to be done, not just stories. Have 10 stories left is very different to having 140 tasks left. Especially if the roadmap is used as a reporting tool for senior/ executive management to see how multiple projects are tracking as they close in on release date.

Better yet is would be great if sub-tasks just inherited the fix version of their parent, but that's another topic.

For what it is worth, better visibility of sub tasks is vital to my sprints when planning, they have separate estimates and often are not assigned to the same resource as the 'main' task.  It is necessary to manually total this for each resource and then add it to the estimate for any main tickets they might have.  I am not concerned about scheduling them independently of the main task, just seeing a true picture of my resource deployment for any given sprint.

Like Lori Insko likes this

I find it more annoying that I can't see my sub tasks in the active sprint. Showing sub-tasks in active sprint lends itself to transparancy. We can easily have stories spanning a couple of days of work, sometimes more, and for that matter it's a benefit to communicate to your team mates exactly at which state you are with a particular sub task.

Like # people like this

@Nic Brough

I have a task which is split in to two subtasks - one for implementation & UT and one for the integration test. Both need to be finished for the task to be considered complete. Subtasks are with different developers. Now I want to see on my sprint if the estimated time for each developer is do-able (we are not running fully scrum compliant and we have so we don't know our sprint velocity). I can't do this since at the moment the subtask is not being displayed. 

I don't want to use an epic as the top level task because we use epics to group much larger collections of tasks.

nic Community Leader Dec 04, 2018

That still doesn't justify it.  Especially as when you're doing scrum, the estimates are not done on a sub-taks.

Well how should I do the estimate then? Doing ti at the top level is not appropriate, since two poeple have to complete work before I want to consider the task complete.. buut both cacn work in parallel so one ticket doesn't work either.

Like André Drougge likes this

I have similar thoughts as Clair Convoy.

I'm open to changing the way we arrange sprints if JIRA doesn't support what I'm trying to make it do, but so far I don't know a viable alternative to my flow.

Firstly, estimations must be supported for sub-tasks. A user story should be defined with a narrow scope yet expressed in a way that non-technical people can handle, such as "As a user, I want to log in to application". This story must be split up into sub-tasks that relates to different developers, say one sub-task for the API work, another for the UI work. Those sub-tasks must be estimated separately.

JIRA has support for adding a story point field on sub-tasks, which is what we do right now, so we can make these estimations. This feels like swimming against the current since the parent story doesn't take these estimates into considerations - we have to look at all sub-tasks and manually add the estimates together and set the parent story estimate to the accumulated value. This is a real headache.

An alternative would be that the user story to "log in" is too wide of a scope and should instead be "As a user I want the API to have support for login" + "As a user I want the UI to support logging into application". This doesn't make sense since people who write user stories shouldn't need have that kind of technical understanding.

Nic Brough, how can this be addressed in terms of changing our development flow?

I am looking though the backlog view (since the sprint that is shown in the backlog isn't yet started) in order to get a sense of how many story points are assigned to each developer or each team, this is not possible since JIRA doesn't support sub-task level estimation and doesn't list sub-tasks in the backlog.

As seen earlier in the thread, the backlog isn't meant to be an overview of a sprint and their estimates, but rather a place to prioritise issues - what view should I be looking at when I want to see a list of _all_ issues (of any kind, including sub-tasks) and their estimations, for a sprint that hasn't yet been started?

It would be great if that view also would:
- Nest sub-tasks under its parent issue and not be seemingly randomly listed.
- Be possible to filter by assignee or label.

Thanks a lot!

@Nic Brough [Adaptavist]

As it was explained by several persons, there are a lot of real use cases why there is a need to have the sub-tasks visible from the Backlog, which is missing since years and we need to use some workaround to manage our requirements, whereas it could be so easier to handle our work by implementing that simple feature.

There are several tickets related to that missing features that Atlassian should really consider to implement.

And you response like "doesn't justify it", "extra code for no benefit" or other are a non-sense. Several explanations have been provided about the different benefits or the justifications why it must be there.

Hopefully one day Atlassian will listen their customer to implement such useful feature.

Like Phyllis Chang likes this

Please show the subtasks in the backlog

Like Phyllis Chang likes this

we like to quickly skim the sprint tree and understand the total amount hours required for each story and then prioritize them. The parent story current does not include the subtask hours. 


we kind of use kanban and sprint toegether. Moving the story around does not update the Kanban board. Can you advise.

0 votes
nic Community Leader Oct 15, 2016

Ah, now that's related to a different problem.  JIRA Software essentially does not support estimating at sub-task levels.  Move the estimates up and it'll work quite well.

"Moving the story around does not update the Kanban board" suggests that your boards are configured in a way that means some updates don't appear.  We'd have to have a closer look at the configs to help you with that one.

0 votes

I have a question: Is it possible to add a figure on the "main task box" to show how many sub-tasks there are? I want to do this to know which tasks to priorities on the Kanban Backlog board. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Calling all Jira Cloud users! Give us feedback on our exploration of a new navigation.

Hi everyone! My name’s Matt and I’m a product manager at Atlassian. I work in the navigation & findability space for all our Jira Cloud products. We’ve been working on trying to improve the exp...

989 views 15 12
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you