Why is it logical that the total estimate of subtasks are not used in the sprint backlog?

Kasper Sørensen_iizj5d

I have a hard time making sense of the estimate-relationship between stories and subtasks to make it visible and usable in the sprint/scrum backlog.

I simply don't understand why, when subtasks are added to a sprint, their estimates are ignored.

Hope someone can help give some inspiration and an explanation as to why it is logical that Jira is not showing the sum of subtasks estimate in the backlog?

In our workflow a story is usually the sum of its subtasks. Meaning the story is complete when all its subtasks are completed. The story is written in human language, and the subtasks are written for the developers.

We don't really estimate the story itself, as it usually represents no actual work other than meetings held to flesh out its subtasks.

An example would be:

1. We create a story
2. Create three subtasks with an estimate of 2 hours each
3. Add the story to the sprint (all subtasks are automatically added to the sprint)
4. Assign the subtasks to users

Now to what confuses me:

1. Opening the parent story, it shows the sum of subtasks estimate to be 6 hours
2. Jira backlog is showing the total hours estimated in the sprint to be 0 hours.
3. It is showing the list of assignees in the sprint each have 0 hours workload.
4. The Roadmap capacity planning IS taking subtask estimate into account and showing 6 hours allocated

I'm assuming I might be missing something, as the only real way to get around this, as I see it, is to set all subtasks to 0 hours estimate, and set the story estimate itself to 6 hours. But that quickly gets unreliable, if one is not super disciplined in always manually keeping track of the estimate of each subtask, and manually adding them up.

Nic Brough -Adaptavist-

There's a long story here, but to try to avoid an essay, we should look at estimates in two ways.

There are issue-estimates and sprint-estimates in play here.  The issue-estimates are doing what you expect - they're literally an estimate for the current issue (and there's a display of the sum of an issue estimate and all its sub-tasks if you want)

The problem here is with the sprint-estimate.   A sprint is a time-box, into which you throw a load of stories (issues) that you commit to achieving inside that sprint.  The sprint-estimate is the estimate for the whole sprint.  The trick here is to understand that a sub-task is not something you commit to when you're building a sprint.  You commit to their parent issue (and hence automatically all the contained sub-tasks if you have any).   The sub-tasks are irrelevant when looking at the commitment.  

Now, there are a lot of schemes you could try to use for having sub-task estimates, but in off-the-shelf sprint process, they're irrelevant.  Atlassian have not tried to build any support for the various sub-task roll-up in sprint schemes, they've simply gone with plain Scrum, where estimates are only for commitments.

So, most of Jira will happily look at your sub-tasks (and their numbers), but the sprint-related stuff (backlog, board, velocity etc) will not, because sub-tasks are not commitable items.

I'm afraid that to get this to support sprint estimates on sub-tasks, you need to do some automation, building a scheme that will work with Jira to make it behave the way you need.  (One really simple scheme is the first one most people reach for - they add up estimates on sub-tasks directly on to the parent - this doesn't actually work though, and you'll need to be a bit more sneaky)