guide --topic artifacts
How to Read a Burndown Chart: Patterns, Fixes and a Template
Set up a sprint burndown, capture the data daily, recognise the four common shapes, and act on what the chart shows before the sprint is lost.
This guide is about using a sprint burndown at work: setting it up so it tells the truth, reading it every day, and doing something when it shows a problem. You’ll get a daily data-capture table, four chart shapes with what each one usually means, and a mid-sprint check. For what a burndown is, which kind to use and how charts get gamed, read Understanding burndown charts first. It also covers why Scrum treats the chart as optional.
One team runs through every step. Five developers on a gym membership app are starting a ten-day sprint. The sprint goal is “members can pause their membership online”, and they’ve planned 40 story points of work.
Who this is for
- Scrum Masters and team leads who maintain the chart and want it to start useful conversations.
- Developers who see the chart at the Daily Scrum and aren’t sure what to do about it.
- Product owners deciding mid-sprint what to cut.
Before you start
- A sprint with a goal. The chart shows progress toward something; without a goal, cutting scope has no basis.
- A Definition of Done. The chart only burns work that meets it.
- A sprint backlog the team keeps current. If the board is updated once a day, the chart is a day behind.
Step 1: Choose one unit and stick to it
Track remaining work in the unit the team planned with: story points, number of stories, or task hours. Don’t switch mid-sprint and don’t mix them.
Whatever the unit, give no partial credit. A story counts as burned only when it meets the Definition of Done. “80% done” stories are how a chart looks healthy on day eight and fails on day ten.
In the scenario: the team plans in story points, so the chart tracks points. A story’s points come off the chart the day it’s done and accepted, not before.
Step 2: Draw the ideal line, then ignore it
The ideal line runs straight from the planned total on day 0 to zero on the last day. It’s a reference, not a target. Real sprints don’t burn evenly: stories are different sizes and finish in lumps. Only worry about the gap when it keeps growing for several days.
In the scenario: 40 points over ten days gives an ideal of 4 points a day: 36 after day 1, 20 at the halfway point, 0 on day 10.
Step 3: Record three numbers every day
Each day, record what was finished, what was added and what was removed, and work out the remaining total from those. Write a one-line note when something changes. The note is what makes the chart readable a week later in the retrospective. Use the data-capture table in the templates.
Recording additions separately matters. If you only record the remaining total, a day where the team finished 3 points and someone added 5 looks like “the team went backwards”.
In the scenario: on day 4 the team finishes 3 points, and an urgent payment bug worth 5 points is added. Remaining goes from 38 to 40, and the note says why.
Step 4: Read the shape at the Daily Scrum
Look at the chart for thirty seconds at the start of the Daily Scrum. The question isn’t “are we on the ideal line?” It’s “has anything changed that puts the sprint goal at risk?” Compare the current shape to the four patterns in the templates and name the one you see.
In the scenario: on day 3 the line has barely moved in three days: 40, 40, 38, 38. That’s the flat-start shape. The team says it out loud: two stories are waiting on access to the payment provider’s test API.
Step 5: Act on what you see the same day
Every shape points to an action. Do it that day, not at the retrospective:
- Blocked work: the Scrum Master chases the blocker today.
- Scope added: the Developers and the product owner agree what comes out to make room.
- Stories bigger than expected: the team re-plans the rest of the sprint around the sprint goal.
In the scenario: the Scrum Master gets the API access on day 3 by going to the provider’s account manager directly. On day 4, when the payment bug is added, the team and the product owner agree to look at what can come out at the mid-sprint check.
Step 6: Hold a mid-sprint check
At the halfway point, you should have burned roughly half the work. If you haven’t, the team and product owner spend fifteen minutes deciding what to cut to protect the sprint goal. Use the mid-sprint check in the templates. Cutting on day 5 is a decision; cutting on day 9 is an accident.
In the scenario: on day 5 remaining is 35 against an ideal of 20. The Developers and the product owner agree to move the 8-point “export pause history” story back to the product backlog: it isn’t needed for the sprint goal. Remaining drops to 27, and the rest of the sprint is achievable.
Step 7: Finish the sprint honestly
On the last day, anything not done goes back to the product backlog, at full size. Don’t close a story as done with known gaps, and don’t split it to burn the finished half. The chart ending above zero is fine; it’s accurate information.
In the scenario: the sprint ends with 3 points remaining: one small story that didn’t pass review. It goes back to the product backlog. The sprint goal is met, because members can pause their membership.
Step 8: Use the chart in the retrospective
Put the chart and its daily notes on the screen in the retrospective. Ask what the shape says about planning, not about who worked hard. Across several sprints, look for repeats: a flat start every sprint is a planning problem, not bad luck.
In the scenario: the retrospective picks out two things. External API access should be checked during refinement, before a story enters a sprint. And the team agrees on a rule for urgent bugs: they come with a matching removal, agreed with the product owner the same day.
Copy-paste templates
Daily data-capture table
Sprint: ____ Goal: ______________________________ Planned total: ____ Unit: points / stories / hours
| Day | Done today | Added | Removed | Remaining | Ideal | Note |
|-----|------------|-------|---------|-----------|-------|----------------------------------------------|
| 0 | - | - | - | 40 | 40 | Sprint planning |
| 1 | 0 | 0 | 0 | 40 | 36 | Two stories waiting on payment API access |
| 2 | 2 | 0 | 0 | 38 | 32 | |
| 3 | 0 | 0 | 0 | 38 | 28 | Flat 3 days; SM chasing API access |
| 4 | 3 | 5 | 0 | 40 | 24 | Urgent payment bug added (5) |
| 5 | 5 | 0 | 8 | 27 | 20 | Mid-sprint check: export story to backlog |
| 6 | 5 | 0 | 0 | 22 | 16 | |
| 7 | 6 | 0 | 0 | 16 | 12 | |
| 8 | 5 | 0 | 0 | 11 | 8 | |
| 9 | 6 | 0 | 0 | 5 | 4 | |
| 10 | 2 | 0 | 0 | 3 | 0 | 3-pt story failed review; back to backlog |
Remaining = previous remaining - done today + added - removed
Only count work that meets the Definition of Done. No partial credit.Four shapes and what to do about them
1. FLAT START
40 |****
| **
| ***
0 |_________***___
day 1 day 10
Usually: blocked work, or stories
too big to finish in the first
few days.
Do: name the blocker at the Daily
Scrum and chase it today. Split
stories in refinement so
something finishes in the first
2-3 days.
2. CLIFF AT THE END
40 |*******
| ***
| *
0 |___________*___
day 1 day 10
Usually: work done but not "done"
(testing or review at the end),
or the board updated in batches.
Do: finish stories one at a time;
bring testing into each story;
update the board as work moves.
3. RISES MID-SPRINT
40 |** ***
| ** ** **
| * **
0 |______________**
day 1 day 10
Usually: scope added, or stories
re-estimated upward as the team
learns.
Do: record additions separately;
take something out for each
addition. Repeated re-estimates
mean stories need better
refinement.
4. CLOSE TO IDEAL ALL THE WAY
40 |*
| **
| ***
0 |______*****____
day 1 day 10
Usually: well-sized stories
finishing steadily.
Sometimes: smoothed data or
partial credit.
Do: if it looks this neat every
sprint, check that only work
meeting the Definition of Done
is being burned.Mid-sprint check (15 minutes, at the halfway point)
Remaining now: ____ Ideal now: ____ Gap: ____
[ ] Is the sprint goal still achievable with the days left?
[ ] What is blocked right now, and who is chasing it today?
[ ] Was anything added? What came out in exchange?
[ ] Which remaining items are not needed for the sprint goal?
Decision (Developers + product owner): move ____________________ back to the product backlogCommon mistakes
Partial credit. Stories are burned when they’re “mostly done”, so the chart looks fine until the last day. Fix: only work that meets the Definition of Done comes off the chart.
Only recording the total. Added work hides inside the remaining number and the team looks slow. Fix: record done, added and removed separately, with a note.
Chasing the ideal line. The team rushes small items to stay near the line and leaves the hard story for later. Fix: treat the ideal line as a reference; act only on a gap that keeps growing or a shape you recognise.
Reading it, not acting on it. Everyone sees the flat line at the Daily Scrum and nothing changes. Fix: every shape you name gets an owner and an action that day.
Using it to rate the team. The chart goes into a status report and the numbers start being managed instead of the work. Fix: keep the sprint burndown inside the team; use a release burn-up for stakeholders.
Hiding the unfinished work. Stories are closed with known gaps so the line reaches zero. Fix: unfinished work goes back to the product backlog at full size.
You’re done when
- The chart uses one unit, and only work that meets the Definition of Done is burned
- Done, added and removed are recorded daily, with a note when something changes
- The team names the chart’s shape at the Daily Scrum and acts on it the same day
- A mid-sprint check happens at the halfway point, with the product owner
- Unfinished work returns to the product backlog at full size
- The chart and its notes are reviewed in the retrospective, looking for repeating shapes