nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint Burndown chart ignores sub-tasks time estimation

Ido Levi

Hi,

in our company, we are using Story and subtasks. The teams set the time estimation in the subtasks, but we have noticed that the Burndown chart ignores it, and it only presents the time estimation if it was set directly in the Story.

How can we make Burndown chart to show the time estimations from subtasks, and not only from the stories?

Out Jira version is: JIRA v7.6.7

thanks,
Ido

Accepted answers

All comments

Tarun Sapra

Hello @Ido Levi

Possible duplicate

https://community.atlassian.com/t5/Jira-questions/How-can-I-use-Subtask-hour-estimates-in-the-Burndown-Report/qaq-p/443657

Peter DeWitt

@Ido Levi ,That's not going to work. In the sprint reporting, subtasks are considered small parts of the parent issue not separate issues. The idea is that the parent issue would be estimated and assigned effort (points or time) representing the body of work. The subtasks would then be created to help breakdown the work. If you are having issues with the parent issues (stories) carrying over multiple sprints, you might want to think about utilizing Epics more ands then making the stories a bit smaller. Basically shift the organization up a level for issue-subtask to epic-issue.

-pjd

Nic Brough -Adaptavist-

You don't.

Burndown measures your delivery of the items you said you would do at the beginning of the sprint. Sub-tasks are part of those items, not deliverable items in themselves.

Imagine you said "in this sprint, we will build one house". Sub-tasks are things that are part of that, so things like walls, roof, plumbing, electrics etc.

When you're building, you might well finish some or all of the sub-tasks, but their progress is irrelevant to burndown - you can only say the house is "done" when the whole house is delivered. So, Jira ignores sub-task estimates, as they can't add anything to the binary information that an item is either done or not.

Ido Levi

thanks for the replies.

I think I understand the concept of a story and sub-tasks. But I find it a bit strange that Jira allows you to set the time estimation in the sub-tasks tickets and then it even automatically calculate for you the overall time estimation from all sub-tasks and display the aggregate time in the story. I also find it more accurate and natural to do the time estimation for each sub-tasks separately instead of estimating the entire story. It looks to me as Jira does encourage us to set the time estimation in the sub-tasks and having Jira do the calculation and show the overall time in the story for us.

So, if Jira aggregates the time estimation of all sub-tasks and shows it (automatically) in the story, it doesn't clear to me why it is being ignored in the burndown chart?

Why in order see it reflected in the burndown chart, I need to delete the aggregated time estimation (which was calculated by Jira) and re-enter it again directly to the story?

thanks,

Ido

Nic Brough -Adaptavist-

There's a bit of history in this - Jira has always done estimates in the way you say, but Jira Software adds a burn-down chart, which should not use the cumulative totals on sub-tasks because you're supposed to burn-down when the item is complete, not partially.

This leaves s in the odd position that sub-tasks can have time estimates and logs which accumulate on the parent item, but shoud not when you're doing sprints.

Atlassian generally recommend that you use story points for the sprint estimation (and hence burn-down), and then feel free to use time estimates on the sub-tasks as they won't be being used for burn-down.

Most of us have to reach for code when we want to use estimates on sub-tasks, either to add them up ourselves on to the parent (using a derived field for the burn-down) or work out subtracting them from a parent as they're added to sub-tasks.

In order to see it in burn-down without code, yes, you need to move the estimate to the issue level.

Danut M _StonikByte_

Hi @Ido Levi ,

The latest version of our Great Gadgets plugin offers this. The sprint and release burndown gadgets have an option to include sub-tasks, which you could use to achieve this. The plugin is available for both Jira Server (https://marketplace.atlassian.com/apps/1218777/great-gadgets-for-jira-server?hosting=server&tab=overview) & Jira Cloud (https://marketplace.atlassian.com/apps/1216564/great-gadgets-for-jira-cloud?hosting=cloud&tab=overview).

Danut.

agrigul

Sorry, but this is a wrong understanding of separation time and tasks with calculations of sums of it. This is a critical bug for JIRA, a bug of common sense.

>which should not use the cumulative totals on sub-tasks because you're supposed to burn-down when the item is complete, not partially.
> but shoud not when you're doing sprints.

Of course it should. It must use totals in any type of issue. At least, because the time spent of Story (1 hour for meetings) and the time of sub-tasks (30 minutes for front, 40 minutes for back) in this story are 2 different times. and they also summarize as 1h + 30m + 40m = 2h 10m.

>use story points for the sprint estimation
this is not about usage of story points, but about usage of logged time. Also, If you don't split story onto front and back sub-tasks and don't estimate separately then you have a very bad accuracy for the whole story.

Nic Brough -Adaptavist-

>Sorry, but this is a wrong understanding of separation time and tasks with calculations of sums of it.

Yes, but it's your understanding that is wrong, not Jira's.

>This is a critical bug for JIRA, a bug of common sense.

There is no bug in Jira here, it is behaving as designed and as intended.

No, I'm afraid you are not understanding what sub-tasks are. They are part of a story, not a sprint-able thing in their own right. Their estimate is an irrelevance to the sprint, because it should be part of the story.

Sprint estimates should take no account of sub-tasks independently, only as part of the sprint-able story.