Burndown Charts Explained (and How to Read Them)

A burndown chart is a simple graph that shows how much work remains in a sprint over time. The vertical axis is remaining work, usually in story points or hours; the horizontal axis is days in the sprint. An "ideal" line runs from the starting total down to zero, and the actual line shows what really happened.

It is one of the cheapest early-warning systems in agile. A glance on day four tells you whether day ten is in trouble.

How to read the chart

There are two lines to compare:

• The ideal line is a straight diagonal from total scope on day one to zero on the last day. It assumes work finishes at a steady rate.
• The actual line drops when work is completed and rises when work is added.

If the actual line sits above the ideal line, you are behind. Below it, you are ahead. The gap matters less than the trend over several days.

Five patterns and what they mean

1. Tracking close to ideal. The healthy case. The team planned realistically and finishes work steadily.
2. Flat, then a cliff. Nothing moves for days, then everything drops at the end. Usually means work only counts as done when it is all finished, or stories are too big. Split them smaller.
3. Line goes up. Scope was added mid-sprint. Sometimes justified, but if it happens every sprint, protect the sprint better.
4. Flat line, never reaching zero. The team overcommitted, or got pulled onto unplanned work. Check your agile velocity before planning the next one.
5. Drops too fast. Finishing early is fine once. Every sprint suggests the team is underplanning or estimates are inflated.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

Burndown vs burnup

A burnup chart shows completed work rising towards a total scope line. Its advantage is that scope changes are visible as a separate line, so you can tell "we slowed down" apart from "someone added work". Many teams use burndown inside a sprint and burnup for longer releases.

Mistakes that make burndown misleading

• Updating tickets late. If people move cards on Friday, the chart shows a cliff that never happened.
• Counting partial progress inconsistently. Pick one rule and stick to it. Story points usually count only when a story is done.
• Using it as a performance score. The chart is for the team to steer, not for managers to grade. The moment it becomes a target, people game it.
• Ignoring testing. If "done" excludes QA, the chart looks great and the release does not. A shared definition of done fixes this.

Jira burndown and the alternatives

Jira offers burndown charts as part of its sprint reports, with options for story points, issue count and time, and it is a familiar reference point for most Scrum teams. If you are looking at a Jira alternative, check that burndown sits alongside the other numbers you report on, so you are not stitching together a picture from several places.

How Flow helps

• Burndown in project reporting. Flow's reporting shows burndown together with sprint figures, time, issues, releases, test runs and sign-offs.
• Sprints that close cleanly. Start, complete and bulk-complete sprints, so the chart reflects real sprint boundaries.
• Project health with reasons. Livex Flow scores health across five areas, explains in one sentence why the score moved, and links findings to the exact tickets.
• AI daily update. A plain-language summary of a person's day helps explain the bumps in the line.