How to create a Sprint Burdown Chart in Jira with subtasks

Danut M _StonikByte_

Hey everyone 👋 

We’ve seen a lot of teams struggle with sprint burndown accuracy when their work is split into subtasks. Jira’s default charts tend to skip subtasks entirely so even when your team finishes a ton of work, the burndown barely moves.

Here’s how we’ve been approaching it using the Great Gadgets app for Jira and Confluence and how you can get a clear, real-time view of your sprint progress with subtasks included.

Challenges with Jira’s Native Sprint Burndown Chart

Jira’s native Sprint Burndown ignores the sub-tasks, only showing progress when parent stories are closed. That means your chart doesn’t really tell the full story until the very end of the sprint.

The solution: Great Gadgets for Jira or Confluence

With Great Gadgets, you can finally build burndown and burnup charts that actually reflect what’s happening day to day.

✅ Include subtasks (or track only them if you prefer)

✅ Customize estimation methods for your team’s workflow

✅ Switch between burndown and burnup views

✅ Get real-time, visual insights, right inside Jira

Great Gadgets app offers a Sprint Burndown Burnup Chart gadget that allows tracking sub-tasks.

💡Tip - You can even visualize a complete sprint report with subtasks included, which you can easily export it to CSV for analysis or sharing.

Why It Matters

With subtasks included, your burndown chart becomes a true reflection of sprint progress. Teams get better visibility, Scrum Masters run smoother retrospectives, and no one wastes time explaining why charts look “stuck.”

Are subtasks supported in other app gadgets?

Great Gadgets offers many other gadgets that can include the subtasks in their calculations:

• Team Velocity gadget
• Release Burndown Burnup Chart gadget
• Cumulative Flow Diagram (CFD) gadget
• Control Chart gadget and more.

So all you need for an insightful dashboard, with full support for subtasks.

👉 If you’d like to test it out, it is free for 30 days on the Atlassian Marketplace:

• Great Gadgets for Jira Cloud
• Great Gadgets for Jira Data Center
• Great Gadgets for Confluence

Bill Sheboy

Greetings, community!

For those wanting to measure based upon their breakdown to sub-task levels, perhaps consider learning more about the history of burn charts, and how that compares to what your team wants to learn from measurement...

A long, long time ago (in agile years), teams sometimes used two charts: the burndown and the burnup:

• the burndown showed any effort measurements, such as in working hours, and included all child work items such as sub-tasks
• the burnup showed individually releasable work items as they completed, often measuring as a cumulative count of items or some value-proxy (e.g., story points, forecasted earnings dollar value, etc.); this chart did not include sub-tasks as they were not usually individually releasable.  (Aside: in Jira, sub-task types are part of their parent item, and I suspect were not intended / considered individually releasable work items with value for a team's customers.)

When these two charts were placed side-by-side (with the burndown on the left side), the team might get a better feeling for what was happening.  That is, when effort was spent consistently and value was delivered consistently per the iteration plan, the combined, actual trend lines' shape looked like a "V" when everything was going well. 

This was called the "Agile-V", and it could indicate process anti-patterns earlier, such as burning down effort but not delivering any value on track with the iteration timeframe.

All that to say, when deciding to measure sub-tasks, please consider what those sub-task represent as work items relative to the value delivered to your customers.  Adding measures for value-delivery may help if it is not already happening.

 

Kind regards,
Bill