Sub-Tasks on backlog

[Casey-Lea Olson]

How can I show sub-tasks on the backlog view? 

I have a design team who get tasks on a dev user story for the design. I have setup the board so that anything labelled with design shows on their board and backlog, however  they are not seeing this on their board, it is only the sub-task labelled but I can't get subtasks to show in this view. 

[Nic Brough -Adaptavist- · Accepted solution]

You will need to find a field that displays the sub-tasks as part of their parent issue.

Sub-tasks are normally not displayed on a backlog view and it doesn't make sense to try to rank them or put them into a sprint outside their parent; so even if you do show them in a backlog, there's nothing you can usefully do with them.

[Casey-Lea Olson]

Thank you Nic. I tend to agree with you, and its good to get the same answer from the community, it just confirms what I was telling them to start with. 

Just not sure how to deal with design tasks though. Do they get logged as their own stories in their own backlog and once done a story is logged for dev? The devs have specified that they will not accept a story into the sprint without the design completed? 

Any other ideas are welcome :D

[Nic Brough -Adaptavist-]

That sounds like design tasks are done outside the developers sprint.  You could do them as sub-tasks, with the designers working on them outside the dev sprint and the devs ignoring them until that sub-task is closed.  Or separate them completely, having their own issue type or even project, then your developers could ignore any story that does not have a link to a closed design task.

[Max Richardson]

I don't agree that it is nonsense to put a sub-task into a sprint outside of their parent. Similar to Casey-Lea's situation, our focus is on design sub-tasks. Design is intimately linked to the corresponding story so it is right that it is expressed as a sub-task. To separate it out would be unnecessarily complex. 

At the same time, the design needs to take place at least one sprint ahead of the work on the parent Story. So subtasks in backlogs/sprints (would) serve two purposes - they highlight which stories in the backlog have yet to be designed, and they reserve a place in the sprint in which they are completed.

Is it really the case that subtasks can be displayed indented in this manner? And if not, what was the configuration (that I have a vague memory of) that allowed handling of subtasks in exactly this manner? 

[Alexey Trofimenkov]

Anothe case using sub-tasks on backlog is connected with quick filters. For instance I have a dev team and a filter for each assignee. I have a couple of planning sprints. Any developer can be assign to either task or sub-task issue. Filterring issues by assignee I see tasks only and this is wrong picture. Moreover a developer filtering his issues will see only tasks or even nothing. All his assignments to subtasks will be hidden
I'm not talking about neither separate subtask ranking nor adding subtask into sprint without parent task. Just only about participating in filter result

[Jeroen Benjamens]

I totally agree with alexey. Please make it possible to view the sub-tasks in the product backlog. This wil make Jira more usefull for projectteams.

[Judy Colonero]

I have had the same request from my engineers.  When they are in the backlog view they want to see ALL their issues, stories and subtasks. 

[Evan Bovie]

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

[Deleted user]

Then give us the ability to add a "Task" to a US because Tasks show up in the Backlog 

[Abhishek Kalikota]

https://jira.atlassian.com/browse/JSWCLOUD-7992 is created in 2013. 

Not sure how long one has to wait for this feature, while it adds more value for many organizations & their way of SCRUM..

[Ram Subramanian]

Maybe there could be an option to include subtasks or not include subtasks. But making a unilateral and unfounded assumption that it is irrelevant is incorrect.

[ppanzella]

So is there any solution to this at all?

Here's my thing...I need to do what's best for me, my team, and how our company does business.  Right now, Jira does not function the way I need it to but unfortunately this software is what my company has chosen to use, so I'm stuck with it.

So I'm asking this question again for everyone who still wants a solution to this issue... How do you make subtasks and the estimated hours with them viewable from the backlog view?

The issue I run into is that while we have a development task, there are steps like QA, Code Review, and Development that are all done by different resources over the lifecycle of that task.  I need to be able to see at the beginning of a sprint exactly what work is on a resource's plate.  At the end of the sprint, I need to see exactly what work each resource has completed.  I currently can't do it the way Jira is currently configured.

@Nic Brough -Adaptavist- - PLEASE do not respond to this comment unless you're actually providing a solution to the problem and not just providing yet another overly pious response on how we're all wrong and not doing Agile or Scrum the right way.  

[Nic Brough -Adaptavist-]

I'm going to have to rise to that because you've explicitly called on me.

This is a scrum tool and it works as such; what you're looking to do falls outside its functionality. As you have more nuanced needs, you could explore automating a solution that allows you to make Jira work the way you want to use it for your process.

[Nick]

At the moment we scope that stories are defined by business demand and we put story points on stories and time estimates on task. Each story has automation (typically set by labels we've defined) that creates "tasks" with a relationship of "sub-task/parent of." The automation checks for label and if task type doesn't already exist in the relationship it creates it and it is available in the sprint like any other task (could even make this a different issue type if you'd like). 

Here is a sample of one of the automation in case that helps. At this point we only actually use "sub-task" then for personal separation of work. This does the trick for us and allows us to create a template for each task type so there is a consistency. We have things like the following but you can configure to your teams needs:

• Requirements Gathering
• Solution Design
• Development
• Functional Testing
• UAT
• Deployment

[areynaldos]

@ppanzella , unfortunately, I have to agree with Nic on this one. You are having issues because what you are trying to do does not match an Agile pattern.

What I would suggest you do is:

• Split your task onto multiple subtasks, each of them reflecting what each team member / step of the process it should belong to.
  People can then log their time on the subtask
• You can also have people log their time in the main task, and then use the JIRA reports to break it down by resource.
  Timesheets comes to mind.
• Otherwise, you can write your own reports using the JIRA API to summarize / break down the work spent by subtask, person, etc.
  Some JIRA reporting tools and plugins will automatically roll up the time to the parent task, or give you the option to report individually.

If you're not happy breaking down in subtasks, you can always break your tasks into multiple ones, each of them with a suffix indicating each of the steps. This would lead to a different kind of nightmare, depending on the size of your team and the amount of tasks you have, but it's another option.

All of this sounds complicated because, as mentioned before, that's not the way it is supposed to work, but at least subtasks and custom reporting or plugins will give you a solution

[Babis Paravalos]

It seems that this has been an ongoing request for 7 years now. I find it hard to believe that a company that provides a solution to make agile software development possible, is not agile itself (unless, they just don't want to add this feature, but they don't tell us why).

[Nic Brough -Adaptavist-]

Yes, Atlassian are well known for not doing requests.  My favourite example was one that took 15 years (and gathered huge numbers of votes).

However, the age of this one is not important.  They've not included a subtask display in the backlog because it's not a lot of use.  A backlog is intended to be used to rank your issues in importance and then build sprints from them.  Subtasks are part of their story in a backlog. 

• You're not interested in ranking them in the backlog, because you can't.  Their overall rank is defined by their story, relative to others, and you can only rank subtasks within their story
• Equally, go into a sprint as part of their story, so there's no point seeing them for that either.

In fact, Atlassian did try displaying them in the backlog briefly, and got a resounding "get rid of this noise" from all their scrum teams.  So they removed the automatic display but left open the option to put the list into the view if you need it.

Go to Configure Board -> Card Layout and add a new field to the "backlog" section.  You should find "Sub-tasks" on the list.

This will display a list of all the subtasks on each story in the backlog.  You can't do much with them because of the stuff above, but you can see them and click their links to view their details.

[Babis Paravalos]

Thank you for your reply. I was not aware for this. Thanks for sharing!

It's good, but still not what I was after. I wanted to have the subtasks visible so I can see them in every person's backlog, for example when I have a parent task and 5 subtasks, and I've assigned each of them to different people, I'd like to go to each person's backlog and see the subtask in their backlog, along with status and estimates. But I can only see the parent task, so if person B is assigned a subtask then it's not straight forward to someone that looks in their backlog, to see that they have that task in the sprint as well! So showing just the subtasks is not very helpful for this use case.

BTW, the remaining estimate that is show is only from the parent task, it's not including the sub tasks, however if you go to individual task view, there is a checkbox to include the sub tasks' estimate to the remaining estimate (but only on this view).

Well, it seems that everyone has their own angle of view and how the utilize each component. Thanks for the help anyway!

[Aaron Reynaldos]

Funny enough, I found this thread because I want to get rid of the sub-tasks in the backlog. I am not certain when they started to appear, but they add too much noise for the reasons stated by @Nic Brough -Adaptavist-  before: you work with stories in the backlog, and you plan your sprint based on stories not subtasks.

The usual behaviour was to show sub-tasks in the Active Sprints view, but not in the backlog - which I believe makes sense from a Scrum approach.

But now they do show in both Active Sprints and Backlog.

So, how do I remove sub-tasks from my backlog? If I modify the filter to exclude them, they won't show in the "Active Sprints", where they do have a value.

Thanks!

[Casey-Lea Olson]

Interesting point - Our design team stopped using Jira altogether and moved to Asana because we could not find way to work with them and Jira, while they are 'part of the dev team' they are not 100% assigned to that team and as a design team they also needed to be able to plan (outside of the project team) as well as have an overall view of what was going on in design. 

[Nic Brough -Adaptavist-]

I'm sorry that your design team have moved to a weaker tool, it must be a right pain having a team that's not working properly with others.

[Casey-Lea Olson]

I am also sorry :) I do believe that its at least 50 / 50 - 50% the tool couldn't do exactly what they wanted and 50% they didn't want to try and figure out another way

[Michael Sanchez]

It *is* a pain working with the chaos that cross-functional teams, that might not be Agile-focused, often present. All the more reason for JIRA to offer the flexibility to organize data any way we might then need to - even if that end is the very functional and common exercise of coping with cross-team dysfunction or misalignment. How "weak" of JIRA not to consider solving for the obvious needs of their customers.

[Allen Curtis]

I agree that the sub-task implementation is flawed and/or broken. The only way to make a hierarchical relationship is to use sub-tasks. However this is limited to since you can not create sub-tasks of sub-tasks.

The intent of "Story" is a prime example. You can see the relationship is Epics and their parts. However this is now way to create tasks which are part of a Story. I created a new link type to try to show this but the relationship is mostly invisible.

Thanks for the "Asana" reference!

[Ram Subramanian]

Subtasks have to be planned for like tasks and epics. It is absurd to say that subtasks are irrelevant. I do hope Atlassian corrects this huge gap and includes sub-task in backlog and board

[Nic Brough -Adaptavist-]

I don't think you understand what a backlog is for.

[Joe Shields]

Not useful feedback Nic. This entire thread is a collection of people who use backlogs and have reason to see subtasks in the backlog view. My team prioritizes and adds point estimates in the backlog view.  I'd like to point and prioritize sub-tasks along with stories. Do I also not understand what a backlog is for? 

[Nic Brough -Adaptavist-]

I know that was terse, and very grumpy, but it is still right.  It is grumpy because I am so very tired of explaining it so so so many times.

Subtasks have no place in a backlog, because they are not items you commit to doing outside of their parent story.

Your teams are doing everything right, but you need to forget sub-tasks, they are not what you are saying what you will do, they are just parts of their parent items.

Could you explain how that is wrong?

[Nick]

@Nic Brough -Adaptavist- I tend to agree that I think "sub-task" by definition have a much narrow scope, for example, I believe sub-task are for the individual to break out their work as they wish but they are to small to be managed by the project.

With that, I do believe many of the use cases promoted in this thread are related to dependent "tasks." Although they appear the same in that there is a dependency, they are in fact separate pieces of work like, ie. design, test, deploy, etc. and they are not hierarchical like sub-tasks. The value then, is that individuals can break out their work as needed without cluttering the backlog. 

Even though that is the way I see it, I think interpretation and expectation of agile teams is that they can adjust these things to fit the needs of their teams dynamics. Considering the backlog is based on some of the boards settings I don't understand why my board can see subtasks but my backlog cannot.

Rather than arguing how one should organize their work, the idea that a "view" powered by JQL can't include sub-tasks (even though a board view can) doesn't make any sense.

[Nic Brough -Adaptavist-]

The reason your backlog does not contain sub-tasks is because they are simply clutter.  The backlog is for ranking and sprint planning, which subtasks have nothing to do with.  

In fact, you can see them in backlogs - add the "sub-task" field to the backlog card display.  Of course, you can't actually do anything with them (other than see that they're there) because they are not sprint items, they are part of their parent issue.

[Babis Paravalos]

What about cases that the parent issue has to be splited in many subtasks, each assigned to different people, in the same sprint? If those are not available in the backlog, then how can we plan the sprint without seeing those? Don't tell me to use an epic for that. Otherwise I will need to have an epic for each task I need to break down - and I have already too many epics that describe a more generic group of tasks - really EPIC (not a few tasks that can be done within 2 sprints). So I think maybe something is missing in between and epic and subtasks, if we want to conclude somewhere?

Since you claim that subtasks are clutter in the backlog, and that those are to just split the parent task into smaller ones (meaning that the main/parent task will be owned by a single person?) then why even use Jira to log the subtasks and not write them down in a piece of paper, which will be quicker?

[Nic Brough -Adaptavist-]

>splited in many subtasks, each assigned to different people, in the same sprint? If those are not available in the backlog, then how can we plan the sprint without seeing those

Sprint planning is choosing what stories to commit to in your sprint.  You do not commit to doing sub-tasks, they're part of a story.

Sub-tasks are there to do things like breaking up stories into more manageable parts, whether for component, technology, assignee, whatever, but they're pieces of a parent, not individual items.   

[Nick]

The reality of our team (not a software development company) is that we cannot always commit to the complete story in a given sprint, instead we must progress the story by committing to requirements gathering, design/solution, or even development but without UAT and deployment. Your rigid (not very agile) expectation is to either 1) put the story on the sprint knowing it will not be 100% complete (lie to stakeholder) or 2) Leave it off the sprint and just work the subtask with no visibility (hide from stakeholder). 

My ideal (and not very unrealistic expectation) is to commit the tasks that will be completed within the sprint based on our realistic ability/velocity. I get your point, but your team has a different definition of done, and likely a lot less competing priorities.

Considering your single-minded perspective throughout this entire post (which at times I see is actually helpful) I'm not trying to convince you otherwise, the point many of us are advocating, is that an agile software tool should be agile. Even in the way they have defined classic from next-gen I would see room for next-gen being rigid because it is intended to fit that pre-defined type of team, but classic is meant for advanced/flexible configurations. 

Now that we have confirmed Jira's disconnect with this "sub" type issue, I think for people in similar situation to me it makes sense to have "tasks" linked to the story so they can be treated like first class citizens in the sprint planning and although they will add some noise to the process, the actual effort of the team can be properly managed. Also that's what filters are for so I don't expect it to be much of an issue.

[Nic Brough -Adaptavist-]

That basically means you are not being Agile at all.  The whole point of the sprint idea is that you deliver within a time-box.

You have headed towards the right way to do it though - split up the stories so that they can fir within a sprint.  That's what Scrum recommends instead of having stories move across sprints because they're too large.

Basically, your problems go away by not mis-using subtasks and doing backlog refinement better.

[Nick]

"As per statistics, it is the flexibility of agile that makes it 37% faster and 16% more productive than the conventional project development model."

That statement is backed by the idea that there is not one agile way, but rather principles to adhere to, such as, "Individuals and interactions over processes and tools." So in this way we expect the the tool to not force certain definitions, ie. whether I call them "subtasks" (children) or "dependent tasks" (siblings) the work that I'm describing has been defined by the team and needs to be captured in order for our non-digital business to begin to value everything that goes into what we deliver.

We are not looking to take a business defined user story and make it any smaller because that creates unnecessary work and possible dilution of the user's request. So the story definition is fine as-is (if it is bigger than necessary we do split, but many times it's a reasonable change request), but the effort involved spans across and requires multiple people to ensure all global considerations are made. The is demand on the BPOs, PM, Architects, Devs and Testers from various projects and products so they don't have the convenience of collectively committing to a single story.

[Nic Brough -Adaptavist-]

I'm well aware of the Agile principles.

I am not trying to say "you have to do it this way", or that there's anything wrong with what you're doing. 

Simply that if you have stories that are larger than a sprint can handle, you're not doing Scrum.  But you're using a Scrum tool to try to represent your non-scrum process.  So there's a disconnect.

[Nick]

Perhaps this is the difference in "software development" versus "business systems development?" We have stories that can be delivered in a single sprint, but the effort to deliver the story is spread across various individuals who do not sit on a single product/system or project.

So yes, our sprint is more about the tasks that progress the business objectives/values scoped by the stories, but there is not a focus on a single story. Once we complete the digital transformation programme we are in (along wih many other organizations), I imagine that could be possible.

For now, in Scrum fashion, we are effectively committing to and delivering iterable change across global regions, business units, systems and M&A initiatives. Are only disconnect was what it appeared Jira was capable of. I personally didn't care if subtask or dependent task, I expect that JQL effectively sees both within a board and can filter them all the same. 

[Michael Fasani]

It was enough for me to see them like this. I can see I have 4 tasks, 2 complete.

I show:  status. labels and sub-tasks.

Goto: Board Settings > Card Layout and choose the fields you want to display.

[Deleted user]

Hello all!! :D 

A possibility better solution is to simply added the JQL similar to

"Epic Link" in (XXXX-0001, EMPTY)

Sub-tasks do not have an Epic links.....but neither do epics!

This works in my Kanban and Scrum boards showing the Parent User Story and Sub-tasks !

Hope this helps ^_^

[border_water]

@[deleted] 

can you please explain on how to implement the above JQL ?

thanks

[Dave F]

If your project uses Epics and Sub-tasks, that idea appears not to work out so well. Good thinking though

[Irka Bek]

Hi,

I think I found a way to filter in backlog view  according to sub-task assignee, I've used:  or issueFunction in parentsOf("assignee = IRINA") and saw dev stories in backlog view where IRINA is an assignee of a sub-task and not necessarily assignee of the dev story

[Mani_Vannan]

This is individuals view. Yes, its possible for an individual to create a filter for his viewing.But my requirement is the team wants to view it on scrum board (holistically).

[Mani_Vannan]

@Lisa Schaffer  is this something you can help? I did find you answering something similar in the forum