Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

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

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

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.

Screenshot 2021-06-20 at 19.02.04.png

1 answer

0 votes

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)

Hi Nic

Thanks for your answer, and for taking the time to help.

If one should follow Jira's vision of how to use sprints, would it then be better to disregard subtasks entirely, as they don't seem to have their place in a sprint, as you don't commit to doing them? I guess there's no point in having tasks in a sprint, you are not committing to do.

Your comment here seems contradictory to me, but I think I get the point.

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

In light of what you are highlighting, why is Jira Roadmaps capacity planning taking subtasks' estimate into account? What is the sane explanation for the Roadmap going it, and the sprint backlog not doping it?

Below here is a quick drawn up example of a sprint that has one story with several subtasks. The subtask' has estimates but the story doesn't, and Roadmap is using the sum of the estimates, but the backlog isn't?

Screenshot 2021-06-21 at 08.57.04.png

Ok, nearly there,

>would it then be better to disregard subtasks entirely, as they don't seem to have their place in a sprint, as you don't commit to doing them? I guess there's no point in having tasks in a sprint, you are not committing to do.

No, that's not quite what I was trying to explain.  Sub-tasks are not part of your sprint-estimate.  You do not commit to doing them directly, you commit to doing their parents and that draws them in along with their parent.  A sub-task is part of its parent, not a separate entity.  Scrum has nothing to say about sub-tasks, it doesn't care whether you use them or not.  People do, to break up their stories for assorted reasons, but they won't have sprint-estimates because their estimate is "as part of a story which we've estimated at X" already.

Roadmaps looks at the issue-estimates, not the sprint-estimate.

Like Kasper Sørensen likes this

Hi Nic

Thanks for your patience and well-documented answers. In our case, I think we will try to structure it around doing estimates for the Story and as you say, not for the subtasks. I get the theory that you commit to the story, not the subtasks. We will try to switch our thinking to, let's use this estimate to complete the story, and then create the subtasks as needed without estimating them separately, and see how it goes.

It's like doing the reverse of what we are doing now, where we estimate each subtask and make a story out of that.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira

⏰ Day in the life of a Jira Admin!

Hello Community! We thoroughly enjoyed this just-for-fun conversation in the Jira Admin Group about what it's like to be a Jira Admin. For #JiraJuly, our talented designers created these graphics t...

303 views 2 15
Read article

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