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

[Kasper Sørensen]

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- · Accepted solution]

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)

[Kasper Sørensen]

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?

[Nic Brough -Adaptavist-]

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.

[Kasper Sørensen]

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.

[Peter Popov]

I've been banging my head against the wall with this since pretty much every other tool out there can do this. For something as configurable as JIRA, I find it really odd at times that Atlassian all but flat out refuses to support certain implementations of Scrum that don't necessarily fit with their dogmatic textbook views. No, the Scrum guide says nothing about subtasks or indeed sub-teams. Yes, many teams still plan their capacity in ideal or real hours, per person or per discipline. And no, it's not ideal but it is what they do and the tool should serve them, not the other way around.

I am in the exact same boat as Kasper. For reasons that I don't want to go into right now, the team needed to plan a sprint using subtask estimates. I ended up using Excel via the JIRA REST API and running a PowerPivot to do the job. It took just 30 minutes or so to set up and so I'm good for the next couple of Sprints until we can chop the backlog into some saner semblance of PBIs, but I still feel like the most popular tool out there should cover one of the most common approaches to Sprint planning.

[Nic Brough -Adaptavist-]

I'm going to pick up the sentence that explains what you're doing here.

"the team needed to plan a sprint using subtask estimates"

Jira's implementation of sub-tasks is that "a sub-task is wholly part of its parent issue".  This means that the sub-task is totally irrelevant to sprint planning, because you do not commit to doing part of something in a sprint, you commit to the whole story.

There's a very simple view on this that I heard from someone a while ago and helps frame it really easily - "if you're putting sprint estimates on sub-tasks, you're not doing Scrum, and you're probably not doing Agile either".

I agree with the principle that it comes from (again, you commit to a story, not bits of one), but I don't quite agree with the hard "no sprint estimates on sub-tasks".  I'm perfectly happy with them, as long as there is a sensible scheme for rolling them up to the parent so that you can still do Scrum properly with them. 

Jira does not implement any such scheme.  Most of the other tools I've seen that do pretend to support sprint estimates on sub-tasks fail miserably, dropping people straight back into waterfall patterns.

Estimates on sub-tasks is not a common approach to sprint planning, it's a red-flag that you're probably not Agile.

[Peter Popov]

That's exactly. I absolutely agree in principle and if I were to start with a team from scratch, I would not take this approach. However, teams in transition often need to implement some transitional practices until they can get to the next level of maturity.

The context I am starting this from is so far removed from being even remotely Agile that it would be a success for the team if they could just plan two week's worth of work - any work - and deliver even 80% of it. We're talking "stories" that span six months, with subtasks in the days and weeks, most of them sequentially and horizontally split (of course,) half-way done, in an environment that expends more than half of its resources just keeping the product afloat on top of two decades of technical debt.

I'm sure you'll agree that I can't just barge in waving the Guide and Manifesto like some kind of Agile zealot and preach Scrum canon to the masses. It just won't fly. I want to take it step by step. Plan two weeks of work. Fail. Inspect. Adapt. Take a few sprints to get it right. Meanwhile, get your backlog in shape - at least for new items. Start estimating PBIs and not activities. You know, small wins, and for those I need to be able to make small steps.

It's the same with JIRA's Kanban implementation. I am helping an ops team transition to Kanban and they're literally starting from zero - KMM level 0, that is. JIRA lacks support for even the most basic of KMM practices - from personal WIPs to per-swimlane WIP to shared WIPs, let alone more complex concepts like split-and-merge workflows or multi-tiered Kanban. At least these the limitations seem to be arbitrary rather than dogmatic in nature.

[Nic Brough -Adaptavist-]

Yep, I start from "Jira doesn't handle sub-tasks that way", and let people explore why if they want to.  Problem is, if you offer it to a team in transition, they're already going down the wrong path, it's easier to just say "the tool doesn't work that way" and let them work through to "because it's not Scrum, and the tool is a Scrum tool" for themselves, or with you.

[Peter Popov]

I'm pretty proud with the team, actually. They already see that it's against what they know about Scrum (which is very little after just a few hours of formal training) and are looking for ways to improve that. They're already asking about relative sizing and shared estimates - so hopefully it's just a matter of getting the backlog in a good enough shape for it to be refined.

In the meanwhile, I researched the topic some more and it seems Atlassian have finally given up to customer pressure, even if not as a core feature. Check out this post:

How to sum up logged hours using automation in Jir... - Atlassian Community

It uses Project Automation to do what is typically (I think) done with ScriptRunner scripted fields. It's worth a try anyway.

[Nic Brough -Adaptavist-]

Yeah, it's actually an accident, it wasn't designed to do it, but it allows for it.  It will, of course, still break all your scrum boards and reporting.

[Peter Popov]

Hmm... how so? Double accounting? That is, you have 250h in subtasks, they roll up to their parents, and the sprint burndown shows 500h all of a sudden?

[Nic Brough -Adaptavist-]

No and yes.  Let's say you put in:

• Story 4 hours
• Sub-task A: 2h
• Sub-task B: 1h

Here, your sprint estimate is 4h, because Jira does not look at sub-tasks.  But the time that non-sprint functions look at is 7h when you're counting roll-ups.

If you then implement "add up sub-task estimates to parent", you end up with a story that says 7h, burns down correctly, but you've actually got estimates of 10 hours because you're now double-accounting the sub-tasks.

Neither of those ways work consistently in Jira.  The best option is to not estimate sub-tasks.  (There are other ways to make it work, but I am not sure Automation can do it, or if SR on Cloud could)

[Peter Popov]

We're only estimating subtasks, though. For now, anyway. That is, for Sprints 1, 2, and 3 tops. Meanwhile I'll work with the POs to get the PBL in a shape that doesn't resemble a government contract roadmap :-/

If we only estimate subtasks and they add up to the story, I believe Sprint estimates in the Backlog view will work, but the Sprint Burndown report may double dip in those estimates. At least now, with only subtask estimates, it burns down correctly.

On the bright side, if the report does end up double dipping, it will also burn down twice as fast, so for the sake of staying on top of the Sprint, it should do the job, even if the numbers themselves won't make sense.

[Nic Brough -Adaptavist-]

Still won't work, you'll end up with reports telling you different things.