I want to show subtasks in the scrum backlog

[Costin Ghita]

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.

[Andy Heinzer · Accepted solution]

Hi everyone,
Over the last 5 years this topic has racked up a lot of views. In an effort to try to better serve users that come across this post, here is an updated answer.

TL:DR
Only classic Kanban type boards are currently able to display subtask issue types in the backlog. Classic Scrum type boards are not able to show subtasks in the backlog, nor are next-gen project boards able to show these in the backlog.

The longer answer:
I understand that many users that come across this thread are looking for a specific way to configure this. Unfortunately, this is not possible for all board types. That said, most other board types can still show subtasks in the Active Sprint or Board view. But when it comes to viewing the backlog on a board, only classic Kanban currently has this ability. We are tracking feature requests for this, but depending on your platform, there are different places to watch/track this:

• For Jira Server or Data Center users, please see our feature request for this over in JSWSERVER-7992

• For Jira Software Cloud users that want to see this in a classic Scrum board, please see our feature request for this in JSWCLOUD-7992

• For Jira Cloud users that want this within a next-gen project, please see JSWCLOUD-18393

Certainly watching those threads and voting on the respective issue that applies to your product and platform can be helpful in providing additional feedback and guidance to our different product development teams.

Cheers,
Andy

[Joe Harmon]

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.

[Jack Eames]

Completely agree. Our team has recently moved from Kanban to Sprint cycles and we're finding it frustrating that you have to go digging around to see subtasks. It's a barrier to productivity and it would be really great if this was adjusted.

[Evan Bovie]

Vote here! https://jira.atlassian.com/browse/JSWCLOUD-7992

[Thomas Radford]

If you use the Agile Wallboard Gadget on a dashboard to show the board, the subtasks are visible, with a little header box to show the parent.

It is frustrating that I cannot see them on the project board.

[Azfar Masut]

"It allows you to prioritize the sub-tasks within a task"

• you can do this, within the Task/Parent issue view (rank them) or even within the sprint board
• sub-task belongs to the Parent
• You work on it within the parent scope
• Thus, also explains why the estimation doesnt rollup to the parent (related to this understanding of how sub-task work)

With above, am not sure why people kept saying its not working as they expected, where else the use case that's used here just seems off.

Unless someone can further justify why there is a need to have sub-task being planned seperately in the backlog?? And please stop comparing Kanban to Scrum (Sprint), if you're doing that, basically, you know nothing about the concept here..

[André Drougge]

I have some points in my comment below:

https://community.atlassian.com/t5/Jira-questions/How-to-show-the-subtasks-in-the-backlog-sprint-tree/qaq-p/412630#M355781

[Eric_Mertens]

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!

[anitescu]

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

[Rodrigo Silva]

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. 
   
2. 
3. 

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

[Lakshmi S]

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 Brough -Adaptavist-]

Have you added the field to the card layout?

[Rodrigo Silva]

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?

[Jennifer.Gonzales]

This was just what I needed. Thanks.

[Rishi Hiremath]

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

[Tom Cowles]

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

[Leonido Gebhard]

Thank you for this alternative!

[Brian Longstreet]

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

[Mirek]

I have been using Agile and Jira for about a decade (when there was Greenhopper even, no Boards that most of people from this topic probably do not know - except @Nic Brough -Adaptavist- probably) and I have my point of view on this.  I was reading this topic and I think it was nice peace of discussion, so just to clarify of some perspectives...

From the Agile perspective (in short):

Team (responsible for delivering specific tasks) have specific velocity and after time knows how much they can take to do specific tasks. There is also a project owner that works with the business (and stakeholders) should be aware what team is doing and prepare backlog for future sprints. By looking at burndown charts, velocity, team competences and availability we do planning and estimating. We also know how much time we have for each sprint - Usually from 1-4 weeks. We estimate Stories (not sub-tasks). If a story is created as a specific "wish" - e.g  "As a user I would like to see a button here and here, so that other team members can do this and that..  " then it is really good and does not need to have sub-tasks - those however I understand might be useful for someone that is working on it later after sprint started. We got demo meetings and retrospective meetings for some purpose, so that on next planning meeting we know how to estimate (if the story was for example not completed). The whole team is learning together how to plan, estimate and avoid big stories that should be already broken down into smaller ones. If we follow pure Scrum then we do not need to have sub-tasks in the view. 

From Atlassian perspective:

Questions like "Why if Kanban have this feature, Scrum cannot" from user perspective are fine, since we think that you have the code already, simply copy and paste it and vioola! .. No, that is not the case. Every feature that a software development team create (or build) need to be analyzed, tested and maintained later, so if in any way the request is not having value comparing to others it stays in the backlog (simple scrum thinking). Someone behind decide what we have and what features would be build based on current velocity and resources. And speaking of "what we have" ..

From Jira perspective:

Yes, it is possible to show somehow sub-tasks on the Backlog with some details. You can see which tickets have sub-tasks and see details. Below is a screenshot.

Of course there there might be people that say that this is not how it suppose to be showing, but I would say - yes it is there. It is in the backlog. No need to discuss if you extend the list on the backlog view (like in the Kanban view) or seeing the list of sub-task on the right panel. This is there. For me it is enough. I personally do not need sub-tasks in the backlog view, but if I just want to know if there are any I can simply get this view and be satisfied.

[Simon Akbari]

Hi Mirek,

could you please post "how to"-steps for dummies on how to configure that view that is shown in your left screenshot?

That would be very helpful! 

Thank you in advance ^^.

[Mirek]

There is actually only one screenshot (on view), but I guess you would like to achieve how to show the key on the story card. In that case the solution (step by step) was already provided by @Rodrigo Silva (see posts above)  

[Deleted user]

the main issue of your "solution" is that its not a solution to the problem people encounter at all. Yeah great, you get the issue IDs - that tell you absolutely nothing about what the task is about.

I really don't get why on almost every single question people in my company ask me (in this case: "I just want to see in the backlog in a glance which tasks are included in specific stories, why does this work on another board and not in mine?") I search for solutions in your forums and the main two answers are

a) you're using the product wrong (even getting to the point of intentionally misinterpreting the initial question) or
b) it's not needed/not viable/there's a plugin for this functionality.

This simple request has been asked for years now, and I honestly doubt that its a matter of maintaining the feature - we all work in product management somehow, and well, bringing the same dropdown view over from Kanban boards to Scrum boards isn't rocket science.

"For me it is enough. I personally do not need sub-tasks in the backlog view" this is the whole problem - you don't seem to listen to your user base much.

[Mirek]

Andreas, thank you for jumping in into discussion. Just to clarify. I am a Jira user and an admin just like you probably, I do not develop new features. I also have many complains of things that were stuck for years and know that probably this is from some reason. In other word before I complain now that there is not something implemented I am always looking at things from different perspectives and trying to understand.

I gave 3 perspectives that I know are valid. For me if you want to use something related to Agile (like aScrum board) you need to follow Scrum principles.

As I already mentioned the goal of every agile team is to have overtime such a planning, development and release process that can give to the customer something working after 1-4 weeks of sprint.

The idea behind stories, estimating and braking huge stories into smaller is from some reason. If a sub-task is something that is a feature it should be a story and later properly estimated. Sub-tasks are simple tasks that helps give everyone information what is going on the specific story. Those are actually optional. In scrum there is no reason to have sub-tasks, however Scrum view still give you information that there are sub-tasks and the workaround could give you more information about them (you just see then on the right panel and always can click on the key to get all information). The ID is just giving you info that there are sub-tasks.

Kanban is totally different methodology. There is no huge planning, estimating, retrospectives, project owner that do the initial planning before every sprint..There was probably a bigger reason to see those where we do not care about planning and we do not have stories (we can have bugs, change request and other type of tasks). That is also why we see both Kanban and Scrum boards not only Boards..

And the reason why this is not implemented on both is probably due to many more variables than "they already have the code is should be simple to copy paste to other feature".. or "this isn't a rocket science".. Well .. We ask that question all the time.. why this or that feature that is currently on Cloud/Server/Data Center is not on all platforms.. It is similar. We could give feedback but the vendor decide what would be implemented - similar to what you do on the sprint planning.. you need to make a decision which feature would be implemented, and you are making that choice based on something. 

That is why you have extensions which you mention in your second point. People many times do not want to wait for Atlassian to see something, they develop an extension and cover the missing functionality. Additional benefit is that they can get money from it..  BTW - It is an opportunity for you also. And imagine that you as a vendor later if you see that there are many solutions already on the market you do not want to invest much time of your employees to do the same. Feature land on the bottom of the backlog. That is the reason why things are waiting many years and many times you are redirected to install a extension. Remember that everything that you develop is on you later (to maintain this and support). Introducing one new feature can also introduce more bugs that can make people busy to fix them instead of focus on things that really matters.

That what you are doing now - giving feedback is very important. Keep up doing this, but always remember to look at things from different perspectives. It would be easier handle many things not only Jira but even many personal things.

[André Drougge]

Hi Mirek, thanks for some good points. I'm still not convinced about that sub tasks aren't needed in scrum. I wrote in this thread earlier about this, but essentially:

Sub-tasks are needed and needs to be estimated. 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.

I'm looking for a practical way to use JIRA with this in mind, but so far using sub-tasks at all feels awkward but inevitable. Any thoughts?

[Tom Fitzgerald]

Have to agree with Andre - the whole intent of subtasks is to track smaller pieces of work related to that story e.g. backlog grooming / technical analysis / estimation / etc.  If these were all submitted as seperate issues it would become a nightmare to manage in a larger organization.

[Charles Lang]

I am new to Jira and wanted to add on to this conversation because we are using Jira Cloud and I came across this same issue, but with the Default Business Board.  We are using the board to manage work of different IT Infrastructure groups and have a component for each group.

For this discussion please understand that I use Issue and Task interchangeably.

We may have an Issue (task) like "Close out old Change Tickets" that has a subtask for each component which equates to each of the group managers.  This subtask allows each manager to complete the subtask , yet the issue (task) would not be complete until all subtasks have been completed by the managers.

Managers use the Board to see their WIP, but when they view their issues (tasks) on the board, they do not see the subtasks.  They can see them by going to the issues section, but this in my opinion is counter productive to the board and seeing the work in progress.

There is no way to change options for the default Business Board, which I don't understand.  A Business Board has nothing really to do with all of the discussion above regarding if subtasks should be show on a board or not.  I'm not using Kanban or Scrum, just the default business board for manager work tasks.

Is there some way to show subtasks on a Business Board?

Thanks,

Charles

[Lakshmi S]

@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

[Rodrigo Silva]

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 .

[andrzej_bil]

Dear All,

I do not want to jump into discussion around agile, frameworks, practices and so forth. Does sth make sense or not. It depends really from particular case. Please let's be all of us open minded. If you don't need something don't use it, and please do not criticise people that want to use sth.  

I just need a working solution. For me Could Jira which I started to use 2 weeks ago has a lot of missing features that older version of Jira had out of box. :(

One of such things is to see everywhere easily sub-tasks, not only on boards.
Please iIs there anyone who can point out solution, step by step, how to show subtasks on Scrum Boards or in Epic View? Generally everywhere where it is possible.

Thank you in advance. :)

[Peter Jones]

Hi Andrzej,

To support your comment, following a particular framework, or tool for that matter, doesn't make teams agile.  It is all about mindset.

Frameworks and tools should support the ability of teams to support business needs AND support evolving behaviours in the teams (which come from having a truly agile mindset).

I also struggle with a lot of JIRA limitations.  I appreciate that Atlassian have a massive customer base to support, however, they need to find a way of "embracing change" and specifically, "Responding to Change over Following a plan" :)

Best
Pete

[Jan_Denny]

Another possible justification for at least displaying subtasks in the backlog view: 

The Planning Poker Plus add-on by Spartez cannot display any subtask info (ex. Key, Summary) in an asynchronous planning poker session because it pulls all its poker display info from the Jira backlog. That means when my team is estimating stories in Planning Poker, they won't even know if a story has a dozen subtasks unless they opt to click the story key to open the story (which very few will do). Consequently, lots of surprises during the planning meeting when my team realizes they underestimated a story that has a lot of subtasks. 

I'm making an assumption here, but if Atlassian can add the subtask relationship to the Backlog view, perhaps Spartez can then include it in their asynchronous poker sessions.

Here's Spartez' response on this issue, dated 10 May 2019:

Hi Jan,

Thanks for getting back to us with that information. We understand the issue now. Subtasks can be viewed in an interactive session, but not in an asynchronous session.

The reason for this is that we are pulling the information for Agile Poker from the backlog view. In a Scrum project, subtasks aren't visible on the backlog. So we can't display or estimate them. (more on that here)

It is possible to view and also estimate subtasks with Agile Poker if you are using a Kanban board. You could actually create a kanban board for this project, and estimate these subtasks from there. But we recognize this isn't an ideal workaround.

In the meantime, we do have a feature request open to allow estimating subtasks from a Scrum board. We have linked this ticket to that, and if any progress is made there we'll notify you - although we can't make any promises as to if or when this will be implemented.

Sorry we don't have better news. Please let us know if there's anything else we can do for you - we'll be happy to help.

Best regards,
William Schoepflin
Spartez Support Team

[Sergiy Gorchakov]

Atlassian should just give us a 3rd level of hierarchy. Epic->User story->Task. In the same way like we now have for user stories inside epics. In many projects you can't finish a user story in 1 sprint. People are trying to use sub-tasks for this purpose. But of course they are useless if not displayed in a backlog. 

As I see this discussion continues for many years. So it looks like we will never get this feature. Sad. 

[Peter Jones]

I disagree with some of your comments....

On the hierarchy topic I suggest you read David Wienberger's "everything is miscellaneous" (https://www.goodreads.com/book/show/726004.Everything_Is_Miscellaneous).  His view on data structures is excellent and very powerful when put into practice.

On the sub-tasks, in my work environment I am trying to get our PO's out of architectural decomposition / micromanagement.  I would like them to focus on the delivery and testing of business stories.  In this context I would like to get the tech teams to break the stories down into sub-tasks which can appear on boards but not in the backlog.  By blocking the closure of stories with open sub-tasks we will have a solution that works for all parties

[John Chen]

Hello there.  new to the community, not so new to Jira.  I think maybe instead of talking on abstract levels, we can talk about an example, which may help with the debate...

Lets say I run "ABC" car shop (general repairs) by myself.  Customer x comes in, needs to do 1) oil change, 2) change timing belt, 3) replace windshield wiper blades, and 4) do a tune up.  

I then create a "story" of "customer x" with 4x subtasks.  My "ABC Shop" scrum board has many customers, each with their own story and subtasks of things to do.

So, now in a give time period (sprint), I can only do so much.  So, I would do subtask #1 from customer X, then subtask #3 from customer Y...etc.  

In this situation, what is the best way to configure my project so that I can leverage scrum board to see what I need to do within a given time period?

any suggestions would be appreciated.  Thanks.

j

[Nic Brough -Adaptavist-]

This does not make sense in a scrum board. 

A scrum board represents work that a team needs to do.  The backlog of stories are the things you draw into a sprint

Your representation of the customer asking for a service makes sense, as do the sub-task breakdown, but you are thinking of the board slightly wrong.   The board is there to tell you what you have said you would do.  The customer does not care about the sub-tasks. 

The way to see what needs doing is to look at the list of customer services you need to perform.  You do NOT do subtask #1 from customer X then #3 from Y.  You should be getting everything done for customer X before moving on to Y, because that's what you said you would do.  You said you would deal with X first.

It may well be the case that your team has a specialist, so the person who changes timing belts is the only one who does belts, and you don't want them doing anything else because it's a long task and you have to do it for most customers.  That's where that specialist should be picking up the next task on the next customer for themselves.  But they look to the next customer to check if they have a task for them.

[Alexander Bøhnsdalen]

According to the Scrum guide, during sprint planning the Scrum team decides which will be the sprint goal and batch of user stories will be done for the sprint, this the WHAT. So there we pull the selected user stories from the product backlog (backlog in JIRA) to the “sprint backlog”, then as second part of my the meeting the development team should decide “HOW” they will be done, so it they will be by creating the sub tasks at this point “only”, when they are already selected for the sprint as sprint backlog . During the meeting  should be created subtasks if needed at least for the 1sts days of the sprint and be able to give a plan on how they will continue doing that the rest of the subtasks on following days during the sprint. 

That is why you do not have subtasks on backlog or product backlog but only shown in Sprint backlog 

Sprint backlog: 

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product”

... And the part of the plan is the subtasks.

[Jan_Denny]

@alexander.bohnsdalen 

I think most of us are aware of the Scrum Guide, but as the name itself implies - that's just guidance, not a dictum - and it doesn't address the problem on this thread.

It's not an option for my project to just move sub-tasks up a level to story / task, because then our stories / tasks would have to become epics, and our epics would have to become initiatives - and then not only is out backlog way too crowded with too much information, but we've lost the ability to serve our sponsors the information they need at the level they understand. Here are a couple of examples from my Navy project:

• Our Initiatives map to sponsor funding line items, so they are very high level. Our Initiatives contain only Epics.
• Each of our Epics maps to an item in the customer's schedule. This allows us to develop in Scrum, but give our sponsor (and their leadership) the ability to track our progress in the terms they understand - schedules and funding line items.
• Our actual development happens at the story / task level - which is a level that our stakeholders may care about, but our sponsors often don't. But that's fine JQL supports reporting of story / task metadata from the perspective of the issue's parent Epic.

As you should be able to see, Atlassian tools users work in a variety of environments - many of which mandate organization structures that are beyond tool user control, and may not perfectly align with Scrum Guide best practices. But Scrum (and the Atlassian tool suite) can still bring value in these environments IF it's flexible enough to accommodate the things we can't control. 

[Deleted user]

Hi there,

Not sure if anyone has answered this but it is more than possible to show sub-task in a sprint backlog using JQL. For example, in my project consists of the following issue types: Story, Bug, Quality Improvement, Task and Sub Task.

I only want to see Story, Quality Improvement, Task and Sub Tasks in my backlog, so my JQL fo rthis is: project = "BA Quality Assurance" AND issuetype in (Story, Sub-task, Task, "Quality Improvement") ORDER BY Rank ASC.

With this query, I can now view sub-tasks (and all the other mentioned issue types as per the JQL) in my active sprint board.

Hope this helps.

[Deleted user]

You have shared the screenshot of sprint board, not the backlog. All the discussion above is about the backlog view :)

[Peter Jones]

Welcome to the Dark World of JIRA

[Michael Kornatzki]

Hi there,

i am a newbee with the scrum-board and agile working.

In the past we use a bug-issue for the main-development-branch and sub-bugs for every version (branch) we had to fix the bug.
Normally we only have the description in the main-bug no need to duplicate it in sub-bugs.

How do we do it now with scrum?

Should we now create multiple bug-issues and link them together?
We want the ability to see in which version the bug is fixed.
We need a status for every version.

Thanks.

[Frederik Wagner]

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. 

[Nic Brough -Adaptavist-]

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.

[LY]

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.

[Nic Brough -Adaptavist-]

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.

[Costin Ghita]

@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 Brough -Adaptavist-]

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.

[Andy K]

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.

[Nic Brough -Adaptavist-]

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.

[Andy K]

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.

[Nic Brough -Adaptavist-]

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.

[Andy K]

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 Brough -Adaptavist-]

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.

[Nick Scurr]

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 Brough -Adaptavist-]

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.

[Nick Scurr]

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.

[Nic Brough -Adaptavist-]

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?

[Andy K]

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. 

[Rick Villela]

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?

[Nicole Downes]

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.

[Wiz White]

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.

[Mads Mølgaard Andersen]

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.

[Claire Conroy]

@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 Brough -Adaptavist-]

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

[Claire Conroy]

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.

[André Drougge]

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!

[Davy_Tissot]

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

[Igor Popov]

Please show the subtasks in the backlog

[jameshove]

@Nic Brough

Please make sub-tasks visible in the backlog.  I should not have to justify this, but here goes:  Stories and their sub-tasks are refined over time; grooming takes time and occurs over days, weeks, or months. When the sub-tasks are not visible in the backlog the number of clicks and browser tabs I need to determine the state of the grooming is larger by many, many factors.

[Jan_Denny]

Here are a couple of reasons to display subtasks in the backlog view:

1. Assume you're reviewing the backlog for either backlog grooming or sprint planning. However, the backlog doesn't display subtask summary fields, so you create a new issue for an activity that already exists in a subtask. You've now created a redundancy in your backlog that you'll have to waste future time finding and reconciling.

2. Assume you're using the backlog for sprint planning. Since the backlog doesn't display subtask summary fields, you can't accurately estimate the scope or magnitude of the subtask's parent task.

3. As mentioned above, the Jira Poker plugin can only display fields that are displayed in the backlog. Consequently, a Jira poker session will not display subtask summary fields, yielding tasks that are underestimated during the poker session - which creates a whole multitude of problems down the line.