sub-tasks are not visible on backlog

[jmorten]

Have spent some time trying to figure out this with no success....

Here is the case :

• board filter/query shows sub-tasks
• canban board shows sub-tasks
• sub -task belongs to story
• for all sub-tasks and parent story :
  • assigned to the sprint
  • assigned to a team member
  • having same component
  • having same project

And yes, I have tried the following with no success:

• changing swimlanes grouping
• adding sub-tasks to card layout
• changing board query to filter on only sprint id or one project
• changing query to include only component

Any idea that can help me solve this?

[Tom Lister]

HI @jmorten 

In  Atlassian view of agile, only the top level tasks are useful for ranking and planning, so the sub-tasks aren't shown in the backlog. 

it depends how you view sub-tasks. If you need to include dependencies in your planning then the other tools like roadmaps might help.

When you place a Task or Story on the board, it will show its sub-tasks.

[Константин Михайлов]

"Atlassian view of agile" is a correct description. I have no idia on why other community leaders say that Scrum have no place for sub-tasks.

Scrum DO NOT say how you should work with your task and should you or not dismantle a story into several sub-task.

Limiting scrum board to Story only making it useless for companys with big products where you simply can't do a single Story in a regular 2 weeks sprint or if you have to distribute work among team members.

[Nic Brough -Adaptavist-]

Yes, Scrum does not have anything to say about sub-tasks.

That's why they are not sprint items - they're a part of a story, not sprint items in their own right.

Scrum works fine for large companies (certainly better than waterfall) with large stories - remember a part of Scrum is backlog refinement which that includes breaking up stories into smaller parts so they can be completed by the team in a sprint.

[Fernando Trindade]

Even though people say "Sub-tasks have no place in Scrum backlog", they do.

For example, when you are assigning sub-tasks to developers and you are planning future sprints, it is nice to get a view on who is taking the subtasks. For example I wanna know IN THE BACKLOG, what is the "load" for a certain developer. Having that available in the backlog is nice because we can IMMEDIATELY see and have an idea on the workload that person will have.

User Stories will be with the PO, Subtasks will be done and owned by Devs and Testers.... So this makes sense.

[Nic Brough -Adaptavist-]

Sub-tasks have no use in a Scrum backlog (they appear in Kanban because Kanban sees a sub-task as being something that needs doing, just like a standard-level issue.  It does not really do anything with sub-tasks).

• You don't rank sub-tasks outside their parent issue, because they are a part of the issue, not sprint items.  
• You don't estimate on sub-tasks either, their estimate is part of the sprint item of which they are a part.

So, as a backlog's main function is planning, based on sizing and ranking, there's no point seeing sub-tasks in it; they're irrelevant noise.

However, you can get them shown in a basic sense - if you add the "sub tasks" field to the backlog card layout, their keys will be shown as part of their parent issue.