What Is a Burndown Chart? Definition, How to Read One, and Examples

Halfway through the sprint, the team seems to be working hard, but is the sprint actually going to finish on time? The Daily Scrum answers with opinions until someone puts the numbers on a graph. That graph — the burndown chart — is the simplest forecasting tool in Agile, and most teams either ignore it or misread it.

This guide defines what a burndown chart is, explains how to read its two lines in one glance, shows the common shapes that signal real problems, and walks you through building one from your own data. You will finish able to create, read, and act on a burndown chart — for a sprint, a release, or any project with measurable progress.

Quick Answer: What Is a Burndown Chart?

A burndown chart is a graphical representation of the work left to do versus time. It shows remaining work on the vertical axis and time on the horizontal axis, with an ideal guideline from the starting total down to zero and an actual line plotted as work is completed. It is used to predict when all the work will be done — most often in Scrum sprints, but in any project with measurable progress.

The nuance: a burndown chart does not track “how much we did.” It tracks “how much is left.” That single shift in perspective is why it is such a useful early-warning tool — the line falls when the team completes work and rises when scope is added.

What Is the Meaning of a Burndown Chart?

The burndown chart was designed for one question: “Will we finish on time?” It answers it by plotting the amount of outstanding work against the amount of time left. The outstanding work is usually on the vertical axis and time on the horizontal axis, making the chart a run chart of remaining work. “Burn down” means the line should descend from its starting point — the total work committed at the start — toward zero, which is the moment everything is done.

It became famous inside Scrum, where the sprint burndown is updated daily from the Sprint Backlog. But nothing about the chart is Scrum-specific. If you can measure remaining progress on a project over time — construction tasks, marketing deliverables, content production — you can build a burndown chart for it. The Project Management Institute’s PMBOK guide even treats burn charts as a general visual-control technique.

How Do You Read a Burndown Chart?

The axes

• Horizontal (X) axis: time. For a sprint burndown, the days of the sprint. For a release burndown, the sprints (or weeks) of the release.
• Vertical (Y) axis: work remaining. In story points, estimated hours, or count of tasks.

The two lines

• Ideal line (guideline): a straight line from the starting work total at day 0 to zero at the planned end. It is a mathematical projection assuming perfectly even burn-down — a reference, not a promise. It is sometimes called “ideal” precisely because real work never follows it exactly.
• Actual line: the real amount of work remaining, plotted each period. At the start, the actual point equals the ideal starting point; from then on it drifts above or below based on how completion and scope changes compare with the projection.

The three states

The comparison between the two lines is the entire value of the chart. Everything else — the pretty shapes, the daily ritual of updating — exists to keep that comparison honest.

One rule about interpretation

A burndown line that sits above the ideal from day one usually means the original estimate was too low, not that the team is suddenly slow. Teams that habitually underestimate will always look behind; teams that overestimate will always look ahead. If a team’s burndown has a consistent, predictable gap in one direction every sprint, the fix is estimation calibration, not working harder. Some practitioners add an efficiency factor to the projection for exactly this reason — after a few sprints, you can compute how much the estimate error typically shifts the line.

What Are the Types of Burndown Charts?

• Sprint burndown: tracks the remaining work in the current Sprint Backlog, updated daily. Answers “will this sprint finish on time?” This is the chart most people mean by “burndown.”
• Release burndown: tracks remaining work for a whole release, with each point plotted per sprint. Answers “is this release on track?” Scope changes show up as the line jumping up between sprints.
• Epic burndown: same idea scoped to one epic or large feature, useful when an epic spans several sprints.
• Product burndown: the whole Product Backlog over many sprints, effectively a long-horizon forecasting view.

The type changes only the time window and update cadence; the reading rules stay identical.

How Do You Create a Burndown Chart?

You can create one in five steps, in any spreadsheet or Agile tool.

Step 1: Pick the unit and the time window

Choose hours, story points, or task count — and decide whether the chart covers the sprint (days), a release (sprints), or an epic (sprints). Consistency matters more than the choice.

Step 2: Record the starting total

Sum the estimates of everything committed at the start. That is the value of the actual line at day 0, and the top of the ideal line. Example: 50 story points committed for a 10-day sprint.

Step 3: Plot the ideal line

Draw a straight line from 50 points (day 0) to 0 points (day 10). That assumes 5 points burned per day.

Step 4: Update the actual line every period

Each day, total the remaining work on the Sprint Backlog and plot it. Note carefully: the new point is the sum of the remaining work after that day, not necessarily “yesterday’s point minus today’s completed work” — because scope can be added or removed.

Step 5: Review, don’t just update

The chart earns its keep at the Daily Scrum. Above the line, ask why. Below the line, ask whether to pull more work. A burndown that is updated but never discussed is a poster, not a management tool.

A minimal worked example

The ideal line runs from 50 to 0. The actual line started on pace (5/day), then slowed after day 6. On day 8 the team is 4 points behind the ideal (ideal: 16 left; actual: 20). The Daily Scrum surfaces a blocked integration; unblocking it restores the pace, and the sprint finishes on time with 2 points remaining that roll back to the Product Backlog.

What Do Common Burndown Chart Patterns Mean?

• Flat line at the top: no work is being marked done for days. Likely: tasks are started but never completed, or no one is updating status. Fix the status discipline before blaming the team.
• Staircase: short flat steps followed by drops. Normal for teams that complete work in batches (a feature lands when its last task closes). Not a problem unless the steps are long.
• Inverted / rising line: remaining work is growing — scope is being added mid-sprint or estimates are climbing. The Product Owner is adding to the Sprint Backlog, or tasks are being re-estimated upward.
• Scoop (dip then rise): the line falls fast early (easy work) and rises again (new scope discovered). Watch for a second dip; it usually means the team learned something late.
• Cliff (sudden drop near the end): a huge amount of work marked done in the last day or two. Either the team delivered a compressed batch (fine) or work was marked done without meeting the Definition of Done (a quality warning).
• Always above / always below: a systematic estimation bias, not a sprint-specific problem. Recalibrate estimates or revisit the ideal line’s assumptions.

Is a Burndown Chart Only for Scrum Teams?

No. A burndown chart works for any effort where remaining work can be measured over time. A construction crew can burn down the number of outstanding punch-list items; a marketing team can burn down campaign deliverables; an agency can burn down client milestones. The Scrum practice of updating it daily from a visible backlog is what makes it disciplined, but the chart itself is unit- and framework-agnostic. Teams that do not run sprints can still use a burndown on a fixed date range — just keep the cadence (daily or weekly) and the definition of “remaining work” consistent.

Real Scenarios: Burndown Charts in Practice

Scenario 1: A 2-week sprint that almost slipped (software team)

A five-person team commits to 45 story points for a 10-working-day sprint. The Scrum Master plots the ideal line from 45 to 0. By day 6, the actual line is at 26 points while the ideal says 18 — the team is about 8 points behind. The Daily Scrum finds the cause: one developer is blocked on an API dependency from another team. The Scrum Master escalates, the dependency lands on day 7, and the line flattens as the developer catches up. The sprint closes at 41 points. The burndown surfaced a fixable blocker on day 6 instead of a surprise on day 10.

Scenario 2: A release burndown that exposed scope creep (product team)

A release with 180 points starts and the release burndown shows a steady downward line. After sprint 3, the line jumps up by 25 points — a new integration requirement was added to the release. Because the release burndown plots remaining work each sprint, the jump is visible immediately. The Product Owner decides to cut 20 points of lower-value work to keep the release date. Without the chart, the team would have discovered the new work at the end and missed the release by a month. The trade-off: the Product Owner had to make a hard prioritization call the chart merely made visible.

Scenario 3: A non-Scrum team borrows the chart (marketing team)

An operations manager running a 6-week campaign with 60 deliverables (blog posts, emails, landing pages, ads) builds a simple burndown in a spreadsheet, plotting remaining deliverables each Monday. In week 4, the line is at 24 deliverables while the ideal expects 20 — the campaign is slipping. The manager reallocates a copywriter from a later initiative and the line recovers. The chart gave a non-engineering team the same early-warning signal Scrum teams get, with no sprints or story points involved.

Scenario 4: The all-below line that meant nothing

A team’s burndown sat below the ideal line for the entire sprint, looking like success — until the review revealed several stories had been marked done without code review or tests. The Definition of Done had not been enforced, so the burndown measured optimism. The retrospective added an explicit check: a story cannot be moved to done unless the DoD checklist is complete. The following sprint the burndown was honest again — and the team’s real velocity turned out to be 20% lower than the inflated chart suggested.

Common Mistakes When Using Burndown Charts

• Updating without discussing. A chart that is never used in a meeting is decoration. Review it at the Daily Scrum or stand-up.
• Confusing “behind” with “slow.” A line above the ideal is often an estimation or scope problem, not an effort problem.
• Not enforcing the Definition of Done. If anyone can mark work done, the chart measures fiction. Apply a shared definition of done.
• Changing the unit or scope mid-sprint. Points, hours, and task counts do not mix, and scope additions must be visible — not silently folded in.
• Reading one pattern in isolation. A staircase is normal for batch-completing teams; a cliff is a quality warning. Context matters.
• Ignoring the ideal line’s assumptions. If the ideal assumes even burn-down, it is a guideline. Judge the gap, not the line itself.
• Forgetting scope changes. The actual point is remaining work after the period — adding scope raises the line. Log scope changes so the rise is explained.

Know This Before You Choose

Before you commit to burndown charts as your progress tool (and pick the tool that draws them), answer these questions:

• Do I have a measurable unit of remaining work — points, hours, or task count — that the team will update honestly?
• Is the team’s Definition of Done enforced, so “remaining” actually means what it looks like?
• Will someone update the chart every period, and will the team review it in a standing meeting?
• Do I understand that a line above the ideal means “behind expected pace” — and that estimation bias can fake it?
• Do I need to show scope changes? If scope is volatile, consider a burnup chart (which shows the total scope line) instead.
• Which type do I need — sprint, release, epic, or product burndown?
• Does my tool generate the chart automatically, or will I maintain it in a spreadsheet?

Which Tools Create Burndown Charts Automatically?

A few real options, each with honest trade-offs:

• Jira (Atlassian) — the default for Scrum. Sprint burndowns, release burndowns, and velocity charts are built in. Pros: automatic, per-sprint, deeply integrated with the backlog. Cons: configuration overhead; chart quality depends on teams keeping statuses and estimates honest. Best for software teams on Scrum.
• ClickUp — offers sprint and epics burndowns plus velocity inside a broader work platform. Pros: good for hybrid teams mixing Scrum with marketing or ops work. Cons: the burndown can feel like one more view in a crowded product. Best for teams that want Agile charts without leaving a generalist tool.
• Azure DevOps — sprint burndown and analytics with strong capacity features. Pros: solid for Microsoft-stack organizations, ties to work items. Cons: less approachable UI, steeper learning curve. Best for enterprise/.NET teams.
• Trello — no native burndown, but Power-Ups and custom board formulas approximate it. Pros: frictionless board adoption. Cons: the burndown is an add-on; no release-level forecasting. Best for small teams already on Trello.
• Spreadsheets (Excel / Google Sheets) — the universal fallback. Pros: free, fully custom, works for non-Scrum projects too. Cons: manual updates decay fast and nothing enforces honest status changes. Best for tiny teams or non-Scrum projects, as in Scenario 3.

The recurring trade-off is the same across every option: automatic tools lower the cost of keeping the chart fresh, but none of them can enforce an honest Definition of Done. The chart is only as truthful as the team that feeds it.

When a Tool Makes Burndowns Less Effort

If you have abandoned burndown charts before because updating a spreadsheet by hand always dies within a month, a tool that tracks task completion, checklists, and quality control in one place removes the friction. That same connected view is what any serious project management setup should give you: one workspace where the data feeding the chart is updated as a side effect of doing the work. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. In Doitify, tasks carry owners, due dates, checklists, and quality control, and progress flows through boards, calendars, Gantt-style schedules, and work and performance reports — the kind of connected picture a burndown is meant to summarize, without re-keying statuses into a separate chart. If your team keeps losing its sprint picture because the data lives in three places, that unified progress view is the use case it was designed for; if your current chart tells you what you need, keep it.

Conclusion

A burndown chart is the cheapest early-warning system in project management: remaining work on one axis, time on the other, an ideal line for reference, and an actual line you update on a cadence. Above the line, investigate; below the line, decide whether to pull more work in; rising, log the scope change. It works for sprints, releases, epics, and plain projects, in any unit you can measure. The chart itself will not save a project — but the honest conversation it triggers, at the Daily Scrum or the Monday stand-up, is what keeps a deadline real instead of surprising.