How to get/setup a correct Burndown chart from a Sprint?

[Kent Chiu]

Hi,

I need help to generate an accurate Burn-down chart for an active Sprint.

We encountered an issue where, after creating a board and a Sprint, the Burn-down chart displays incorrect data. Specifically, all issues in the Sprint show no remaining time estimates, and only recently logged work tickets appear after the Sprint is set to active.

Not all parent issues have an original time estimate. Instead, their subtask issues contain the original estimates. When viewing a parent issue with the "Include Subtasks" option, the parent issue reflects the remaining time estimate aggregated from its subtasks.

We expect that, upon Sprint activation, all parent issues will display the remaining time estimates aggregated from their subtasks' remaining time estimates.

The Board where the Sprint is located was set as follows:

What did we miss in setting the board/Sprint?

Thank you,

Kent

[Vitalii Rybka · Accepted solution]

Hey Kent! This is a classic burndown chart issue that trips up a lot of teams. The problem is that Jira doesn't automatically aggregate time estimates from subtasks to parent issues when the sprint starts.

Here's what's happening and how to fix it:

The issue: Your parent stories don't have original estimates, so when the sprint starts, the burndown chart has nothing to baseline against. Even though you can see aggregated estimates when viewing with "Include Subtasks," that's just a display feature - it doesn't actually populate the parent's estimate fields.

Solutions:

1. Add estimates to parent stories - Either estimate the parent directly or manually copy the aggregated subtask estimates to the parent before starting the sprint
2. Use subtasks in your sprint - Instead of just adding parent stories, add the actual subtasks to your sprint. This way the burndown tracks the work that's actually estimated
3. Automation rule - Create an automation that copies aggregated subtask estimates to the parent when issues are added to a sprint

Quick fix for current sprint: Go through your parent stories and manually add the time estimates that match their subtask totals. The burndown should start working properly after that.

Most teams find option 2 (adding subtasks to sprints) works best long-term.

[Kent Chiu]

Thank you, @Vitalii Rybka , for your reply and suggestion. This helps clarify the real issue with the burn-down chart. My concern is that if we add the original estimates for the parent before starting the sprint, it will lead to double-counting of the remaining estimates.

Regarding your suggestion to use only subtasks in the sprint, are you saying we should include only subtasks in the sprint and not assign parent issues to it? Subtasks inherit their sprint from the parent issue. Does this mean we must assign the parent issue to the same sprint? I’m unclear about this. Could you please explain what you mean by "use subtasks in your sprint"?

[Danut M _StonikByte_]

Hi @Kent Chiu,

Unfortunately the Jira reports do not aggregates the estimates and time logged on sub-tasks.

You could follow the good advises of Vitalii Rybka. Or, another option would be to search for an app (plugin) on Atlassian Marketplace that offers a report or gadget that can aggregate the time estimates from the subtasks. 

If you consider the idea of using a plugin, our Great Gadgets app offers a Sprint Burndown Burnup Chart gadget that can include the sub-tasks and their estimates. This gadget works with story points, issue count and time estimates. 

On its optional Data tab, this gadget includes a sprint report similar to the one from Jira that can also include the sub-tasks. 

The same app offers many other gadgets that can include the sub-tasks: Team Velocity, Release Burndown Burnup Chart, Cumulative Flow Diagram, etc. So all you need for tracking your agile projects by sub-tasks.  

Danut.

[Kent Chiu]

Thank you, Danut, for your reply. At this time, we are not considering an add-on plugin.