日本語

Burndown Chart: What It Is and How to Read One

Burndown chart with ideal line and actual progress line

A burndown chart is the single most useful signal a Scrum team can look at each morning. In one glance, it shows whether the sprint is on track, falling behind, or quietly accumulating scope that nobody planned for.

Key Facts

  • Burndown charts originated with Ken Schwaber's 2000 paper introducing Scrum process management and have remained the most-used Scrum artifact since (Scrum Alliance, 2023).
  • Teams using daily burndown updates report 17% better sprint-goal completion than teams updating weekly (State of Agile Report 17th edition, 2024).
  • The "ideal" burndown line assumes uniform daily progress, but real sprints show a J-curve with backloaded delivery in roughly 60% of cases (Atlassian community survey, 2023).

What is a burndown chart?

A burndown chart is a graph that tracks how much work remains in a sprint or project over time, with the goal of reaching zero by the deadline. The horizontal axis represents time (days, sprints, or weeks), and the vertical axis represents remaining work (story points, hours, or tasks). As the team completes work, the line "burns down" toward zero.

Burndown charts belong to the Scrum toolkit, though teams using other agile methodologies adopt them too. The key appeal is simplicity: you don't need to interpret dozens of metrics to understand team progress. Two lines tell the whole story.

The chart is distinct from a Gantt chart, which maps tasks to dates, or a PERT chart, which focuses on task dependencies. A burndown chart doesn't care about individual tasks. It only asks one question: how much work is left, and is that number shrinking fast enough?

How a burndown chart works (the two lines)

Every burndown chart has two lines:

The ideal line (also called the reference line or guideline) runs as a straight diagonal from the top-left corner to the bottom-right corner. It starts at total sprint commitment (say, 80 story points on Day 0) and ends at zero on the final day. This line assumes the team burns through work at a perfectly uniform rate each day. Nobody actually expects this to happen. The ideal line exists as a reference point, not a prediction.

The actual line plots real remaining work as it's recorded each day. It's updated at the daily standup or at the end of each workday. When this line sits above the ideal line, the team is behind. When it sits below, the team is ahead. When it goes flat (no downward movement), work isn't getting done or isn't being recorded. When it spikes upward, new scope has been added to the sprint.

The axes:

  • X-axis: Sprint days, numbered from 0 (or 1) to the final day
  • Y-axis: Remaining work, measured in story points or hours

The starting value on the Y-axis equals the total sprint commitment. Zero on the Y-axis means the sprint is complete.

Sprint burndown vs release burndown

Teams use two main variants. They answer different questions and serve different audiences.

Sprint Burndown Release Burndown
Scope One sprint (1-4 weeks) Multiple sprints toward a release
Y-axis unit Story points or hours Stories, features, or epics
X-axis unit Days within sprint Sprints remaining
Primary audience Development team + Scrum Master Product Owner + stakeholders
Update frequency Daily End of each sprint
Key question Will we finish this sprint? Will we hit the release date?
Warning signal Flat line, upward spike Slow burn rate vs. backlog growth

Most teams start with sprint burndowns. Release burndowns become valuable once a team has enough sprint history to project a reliable velocity. Both sit alongside tools like the work breakdown structure and project life cycle planning docs.

How to read a burndown chart (4 common patterns)

Four burndown chart patterns: ideal, behind, ahead, scope creep

Learning to read a burndown chart means recognizing four recurring shapes. Each tells a different story about sprint health.

Pattern 1: Tracking ideal

The actual line stays close to the ideal line, drifting slightly above or below but never straying far. This is what healthy sprint execution looks like. It doesn't mean everything is perfect. It means impediments are being resolved quickly and the team estimated reasonably.

Pattern 2: Behind schedule

The actual line runs consistently above the ideal line. The gap between the two lines grows wider as days pass. By Day 5 of a 10-day sprint, the team may only have burned 20% of work when 50% was expected. This pattern calls for an immediate conversation in the daily standup. Common causes: stories were underestimated, team members are blocked, or the sprint was overcommitted from the start.

Pattern 3: Ahead of schedule

The actual line drops below the ideal line and stays there. The team is burning faster than planned. This sounds good, but it's worth asking why. Either the stories were overestimated (which inflates velocity metrics), or the team is cutting corners on quality. If estimation was simply conservative, the team can pull in stories from the backlog to keep momentum.

Pattern 4: Scope creep

The actual line suddenly jumps upward mid-sprint instead of continuing down. This spike means new work was added to the sprint after it started. A small bump might be acceptable for critical fixes. A large or repeated spike signals poor sprint planning or pressure to accept mid-sprint requests without negotiation. Compare this against Scrum vs Kanban principles: Kanban explicitly allows flow changes mid-cycle, while Scrum aims for sprint stability.

How to create a burndown chart: step by step

Step 1: Gather sprint data

Before touching a chart, collect two numbers: total story points (or hours) committed to the sprint, and the number of working days in the sprint. These define your starting point and your endpoint. Document both in your sprint planning notes.

Step 2: Set up axes

Draw or configure your chart with days on the X-axis (from 0 to final day) and remaining work on the Y-axis (from 0 to total commitment). Label both axes clearly. If you're building in a spreadsheet, freeze the header row and the day column so they stay visible as the sprint progresses.

Step 3: Plot the ideal line

Connect two points: (Day 0, total commitment) and (final day, 0). This straight line is your reference. In a spreadsheet, a simple SLOPE formula handles this. In Jira or Azure DevOps, the tool draws it automatically when you set sprint dates and story point totals.

Step 4: Plot actual work daily

At the end of each workday (or during the standup), record remaining story points. "Remaining" means the sum of story points for all incomplete stories. Don't subtract partial credit for in-progress stories. A story is either done or it isn't. This binary rule keeps the chart honest and avoids false progress signals.

Step 5: Interpret and act

Don't just update the chart and move on. Each day's data point is a prompt for a conversation. Is the actual line above ideal? What's blocking the team? Is a story taking longer than estimated? Do those stories need to be broken down further? The burndown chart is most useful when it drives specific actions, not just reporting.

Burndown chart examples by team

Sample burndown chart for a 10-day sprint showing scope creep on day 6

Different teams use burndown charts in slightly different ways. The core mechanics stay the same. The sprint duration, story point scale, and update cadence shift based on team size and workflow.

Team type Sprint length Y-axis unit Typical pattern Common issue
Engineering (product) 2 weeks Story points Backloaded delivery Stories completed in last 2 days
Marketing campaign 1 week Task count Flat then steep Approvals block progress until Day 3
Design 2 weeks Hours Tracks ideal closely Scope creep from late feedback rounds
Support / ops 1 week Ticket count Often ahead of ideal Tickets resolved faster than estimated

Engineering teams most often see the J-curve pattern: slow burn through the first half, then rapid completion in the second half as integration and review work converges. Marketing teams tend to see flat lines mid-sprint because work piles up waiting for sign-off. Design teams track closest to ideal when sprint ceremonies are respected, but suffer the most from scope creep when stakeholder reviews arrive late.

Burndown vs burnup chart

Burndown and burnup charts are close relatives, but they answer slightly different questions.

A burndown chart tracks remaining work. The line moves from high to zero. The focus is on what's left.

A burnup chart tracks completed work. The line moves from zero upward. A second line shows total scope. The gap between the two shows how much work remains.

The burnup chart's key advantage is transparency around scope changes. When new stories are added, the total scope line moves up, and everyone can see both the added work and progress on the original commitment. In a burndown chart, scope additions appear as upward spikes, which can be harder to interpret at a glance.

Most Scrum teams start with burndown charts because they're simpler. Teams with frequent scope changes often switch to burnup charts because they separate the "how much did we do?" question from the "how much was added on us?" question. Some teams display both side by side during sprint reviews.

Common mistakes (and how to fix them)

Mistake Fix
Counting in-progress stories as partial done Use binary done/not done. No partial credit.
Updating once a week instead of daily Update at standup every day. Stale data hides problems.
Resetting the chart after scope is added instead of showing the spike Let the spike show. It's information, not embarrassment.
Blaming the team for a bad chart shape Use the chart to find systemic causes, not assign fault.
Treating a below-ideal line as purely good news Ask whether stories were over-estimated or quality was cut.
Skipping the chart when the sprint is going badly Bad sprints are exactly when the chart matters most.
Mixing different unit types (hours for some stories, points for others) Pick one unit and stick to it for the entire sprint.

Best practices

  • Update the chart at the same time every day. Morning standups work well because the team discusses blockers right after updating. Consistency matters more than perfect timing.
  • Keep the ideal line visible at all times. Don't hide it when the actual line diverges. The divergence is the point.
  • Display the chart where the team can see it. A shared dashboard or a screen in the team's physical workspace keeps the sprint status front of mind without requiring extra effort to check.
  • Don't add stories to a sprint without adjusting the total commitment. If new work enters the sprint, the Y-axis starting point should reflect the new total. Otherwise the chart understates remaining work.
  • Use the chart in retrospectives, not just standups. The shape of the final burndown is a rich retrospective prompt. A persistent flat-then-steep pattern might signal that sprint ceremonies need improvement or that stories are too large.
  • Pair it with a velocity chart over time. A single sprint's burndown shows current health. Velocity over 5-6 sprints reveals whether the team is improving, plateauing, or declining.
  • Keep story granularity consistent. Stories larger than 8 story points rarely burn smoothly. Break them down. Large stories create artificial flatness on the chart until they're suddenly "done" all at once.
  • Don't use the burndown chart to evaluate individual performance. It reflects team-level progress. Using it to spot individuals who "aren't contributing" misreads the data and damages trust.

Frequently asked questions

What does a flat line on a burndown chart mean?

A flat line means no work was completed during that period, at least according to what was recorded. The most common causes are: stories aren't being closed in the tracking system even though work is done, the team is blocked by a dependency or missing input, or work is stuck in review and hasn't cleared the definition of done. Check the tracking system first before assuming the team stopped working.

What is the ideal burndown line?

The ideal line is a straight diagonal that runs from total sprint commitment on Day 0 to zero on the last day. It represents perfectly uniform daily progress. No real sprint looks like this, and that's fine. It exists as a reference point so the team can see how far actual progress deviates from a theoretical baseline.

What's the difference between burndown and velocity?

A burndown chart shows remaining work within a single sprint. Velocity measures how many story points a team completed across multiple sprints, usually averaged over the last three to five. Burndown is a within-sprint signal. Velocity is a cross-sprint trend. Both matter for sprint planning: velocity tells you how much to commit, burndown tells you whether you're delivering on that commitment.

Should I use story points or hours?

Either works. Story points are more common in product engineering teams because they abstract away individual skill differences and focus on relative complexity. Hours work well for teams with highly predictable task types, like support or design. The most important rule is consistency: pick one unit for your team and don't switch mid-project, or your charts become impossible to compare over time.

How often should I update a burndown chart?

Daily is the standard. Updating at the daily standup or at end-of-day keeps the chart accurate enough to catch problems early. Weekly updates leave a week's worth of risk invisible. Some teams update twice a day during high-stakes sprints, though daily is sufficient for most situations.


Burndown charts work because they surface reality quickly. A team that looks at its burndown every morning can't hide from a bad sprint for long, and that visibility is exactly what makes it useful. Whether you're using Scrum, experimenting with Kanban, or managing a mixed-method project through the critical path method, the burndown chart gives you one clean, honest view of progress. Start tracking today, and you'll find it becomes one of the first things the team checks each morning.