What is a Burndown Chart?
A burndown chart is a visual graph that shows how much work remains in a sprint or project versus how much time is left — so teams can see if they're on track.
A burndown chart is a graph that tracks how much work remains in a sprint or project over time. The Y-axis shows work remaining (in hours, story points, or tasks). The X-axis shows time (days remaining in the sprint). An ideal burndown line runs from top-left to bottom-right — work decreasing steadily as the deadline approaches.
The purpose is simple: at any point during a sprint, you can look at the burndown chart and immediately see whether the team is on track, ahead, or falling behind.
Burndown charts come from Scrum, where they're used at the sprint level. But the concept applies to any time-boxed work: a project, a release, a quarter.
How to Read a Burndown Chart
Three lines matter on a burndown chart:
- Ideal line — a straight diagonal from total work on day 1 to zero on the last day; this is the target pace
- Actual line — the real remaining work updated daily; where this line is relative to the ideal line tells the story
- Scope line — if new work is added mid-sprint, this shows as an upward bump; scope creep is visible on the chart
What Burndown Patterns Mean
Different shapes on a burndown chart signal different issues:
| Pattern | What it means | Action |
|---|---|---|
| Actual above ideal | Team is behind — not completing work fast enough | Reduce scope or add resources |
| Actual below ideal | Team is ahead — completing faster than estimated | Check if work is actually done or being skipped |
| Flat line for days | Work isn't being completed — blockers or unclear tasks | Daily standup to surface the blocker |
| Sudden upward jump | Scope was added mid-sprint | Evaluate if it fits; push back if not |
Burndown vs Burnup Charts
Burndown shows remaining work (going down to zero). Burnup shows completed work (going up to total scope). Both convey similar information, but burnup charts have one advantage: scope changes are visible as an upward shift in the total scope line, not just an upward jump in remaining work.
For teams where scope changes frequently, burnup charts are more transparent. For stable-scope sprints, burndown is simpler and more intuitive. Most Agile tools offer both.
Creating Your First Burndown Chart
A burndown chart tracks work remaining over time. Before you can create one, you need two things: a total amount of work estimated in consistent units (hours or story points), and a deadline.
Step 1: Estimate all work in the sprint or project. Convert every task to story points or hours. Consistency matters — a 3-point task should represent roughly the same amount of work every time.
Step 2: Calculate the ideal burndown line. If you have 80 story points and a 10-day sprint, the ideal line drops 8 points per day. Plot a straight line from 80 (day 0) to 0 (day 10).
Step 3: Update remaining work daily. At the end of each day, sum the story points remaining across all incomplete tasks. Plot this point on the chart.
Step 4: Connect the dots. The actual line connects your daily data points. Compare it to the ideal line. Above the ideal = behind schedule. Below = ahead of schedule.
You can build a burndown chart in a spreadsheet in about 15 minutes. Two columns: date and remaining work. Add a third column for the ideal burndown. Chart them as a line graph.
- Consistent estimation is the foundation — variable story point definitions produce a meaningless chart
- Track remaining work, not completed work — the chart shows what's left
- Update once per day, at the same time each day
- A spreadsheet is enough to start — build the habit before investing in a tool
Burndown Chart for a 2-Week Sprint: Day-by-Day Example
This is a day-by-day breakdown for a team running a 2-week sprint starting with 100 story points. The ideal burndown: 10 points per day over 10 working days.
Days 1-3: The team fell behind. An authentication blocker stopped one developer from making progress on 3 tasks.
Day 4: The blocker resolved. Progress accelerated — the team closed the gap from 14 points behind to 5 points behind in 2 days.
Days 5-7: The team tracked close to the ideal line. Steady progress, no new blockers.
Day 8: A scope addition came in — a client requested a small feature outside the original sprint commitment. The team added it (8 story points) without removing equivalent work.
Days 9-10: The team finished with 11 story points incomplete at sprint close.
The retrospective for this sprint should cover two things: how to handle blockers faster, and why a scope addition was absorbed without removing other work.
| Day | Ideal Remaining | Actual Remaining | Notes |
|---|---|---|---|
| 0 (start) | 100 | 100 | Sprint begins |
| 1 | 90 | 92 | Auth blocker starts |
| 3 | 70 | 79 | Blocker still active |
| 4 | 60 | 65 | Blocker resolved |
| 7 | 30 | 31 | Effectively on track |
| 8 | 20 | 22 | Scope addition: +8 pts |
| 10 (end) | 0 | 11 | 11 pts incomplete |
When to Stop Using Burndown Charts
Burndown charts are useful in specific contexts and misleading in others.
Stop when estimation is inconsistent. If your team's story points vary widely, the burndown line is noise. Fix estimation before relying on a chart.
Stop when scope changes continuously. Burndowns assume you know total work upfront. If new requirements arrive every few days, the chart never shows a real picture. A burnup chart — which shows both total scope and completed work — handles changing scope better.
Stop when the chart changes behavior in harmful ways. If team members start marking tasks 90% complete to make the chart look better, the chart is producing the wrong behavior.
Stop for maintenance and support work. Burndowns suit fixed-scope, time-bounded sprints. Ongoing support queues and bug backlogs have no 'done' state for a sprint — cycle time and ticket volume are more useful metrics.
Stop for very small teams. With 2-3 people and 15-20 story points per sprint, the chart adds overhead without meaningful signal.
- Burndown charts require consistent estimation to produce meaningful data
- Continuous scope change: switch to a burnup chart that shows total scope movement
- If the chart drives gaming behavior, it's no longer a measurement tool
- Maintenance and support work needs cycle time or ticket volume metrics, not burndown
Melororium
Track sprint progress in Melororium
Project management, time tracking, CRM, and invoicing — one flat monthly fee. Starter $29/mo · Agency $59/mo · Studio $119/mo.
Frequently Asked Questions
Do you need a burndown chart for every sprint?
Not necessarily. Burndown charts are most valuable when the team wants real-time visibility into sprint progress, or when stakeholders want to see how work is tracking. For very small teams or short sprints, a daily standup and task board may provide enough visibility without the chart.
What's wrong when the burndown line doesn't go down?
Three common causes: tasks are larger than one day of work (break them smaller), team members aren't updating task status daily, or there are blockers nobody is surfacing. Daily standups exist specifically to catch flat burndown lines early.
What unit should a burndown chart use?
Teams use hours, story points, or task count. Hours are most accurate but require time tracking. Story points require estimation. Task count is simplest — count remaining tasks — but assumes all tasks are roughly equal in size.
Put it into practice
Manage it all in Melororium
Project management, time tracking, CRM, and invoicing — one workspace, one flat fee. From $29/mo.