How do I create a burn down chart in agile project management

TL;DR: Most burn down chart guides show you how to draw the line. This one shows IT company owners how to read it when it goes wrong — covering the three deviation patterns that signal sprint failure before the sprint ends, and the specific actions each pattern calls for.

What a Burn Down Chart Actually Shows

A burn down chart plots two things: remaining work on the Y-axis and time on the X-axis. That's the whole structure. What makes it useful is the comparison between two lines.

The ideal line runs diagonally from the total work estimate on day one to zero on the final day of the sprint. It assumes perfectly even progress, which never happens in practice, but it gives you a reference.

The actual line is what your team actually burns. It updates daily as tasks close. Three shapes appear most often in real sprints:

• A line that tracks close to ideal means the sprint is healthy

• A flat line for two or three days signals blocked work — use bottleneck analysis to identify which stage is causing the pattern

• A line that drops steeply late in the sprint suggests work wasn't being logged in real time, which makes the chart useless as a forecasting tool

The Y-axis can represent story points or hours. Story points are more common on agile burn down charts because they abstract away individual capacity differences across the team.

The chart covers one sprint by default. For a sprint burndown chart and how it maps to a single sprint's scope, that boundary matters — scope is fixed at sprint start, so the ideal line is stable.

Burn Down Chart vs Burn Up Chart: Which One to Use

Both charts track sprint progress, but they answer different questions.

A burn down chart shows remaining work falling toward zero. It answers: "How much is left, and will we finish on time?" That makes it the right choice when sprint scope is locked at day one and your team needs a daily signal on whether they're on track.

A burn up chart splits the view: one line shows completed work climbing, another shows total scope. It answers: "How much have we done, and has the target moved?" Use it when product owners add or remove stories mid-sprint, because a burn down chart will misrepresent progress the moment scope shifts. A sudden scope increase looks like the team slowed down when they didn't.

The decision rule is straightforward:

• Fixed scope sprint (scope agreed at planning, no mid-sprint changes): use a burn down chart. The single descending line is easier to read in a daily standup.

• Variable scope sprint (stories added or removed during the sprint): use a burn up chart. Separating progress from scope change prevents the team from being blamed for a moving target.

If you're building a sprint burndown chart and how it maps to a single sprint's scope, fixed scope is the baseline assumption. Most Scrum teams start there and switch to burn up only when scope volatility becomes a recurring problem.

How to Create a Burn Down Chart in Agile in 6 Steps

Six steps get you from a blank spreadsheet to a working sprint burn down chart your team can read in under two minutes.

1. Define sprint scope in story points: Before the sprint starts, total the story points for every committed backlog item. This number becomes your Y-axis maximum. If your team uses hours instead of points, that works too, but story points tend to produce more stable forecasts because they abstract away individual capacity differences.

2. Draw the ideal burn-down line: Divide total points by the number of sprint days. Plot a straight diagonal from day one (full scope) to the last day (zero). This is your ideal line for the sprint. If you want a data-backed starting point, pull your team's historical velocity to calibrate what "realistic" looks like before you commit — a velocity chart makes this straightforward.

3. Log remaining work daily. At the end of each day, sum the story points still incomplete across all open tasks. Do not log effort spent — log what is left. This distinction matters. A task that is 90% done still carries 100% of its points until it is closed.

4. Plot actual progress against the ideal line: Add the daily remaining-work figure to your chart. The gap between the actual line and the ideal line is where your agile burn down chart tells the real story. A step-by-step walkthrough covers the mechanics if you are building this in a spreadsheet for the first time.

5. Recalculate after scope changes: If the product owner adds or removes stories mid-sprint, adjust the total scope and redraw the ideal line from that day forward. Scope creep that goes unlogged makes the chart misleading — the actual line looks better than the situation is.

6. Review at sprint close: Compare the final actual line to the ideal. Did the team finish early, on time, or carry work over? Use that gap to feed the next sprint's planning. A project tracking dashboard that surfaces burn down data alongside velocity and cycle time makes this review faster and more consistent.

How to Read a Burn Down Chart: Three Patterns That Matter

Once you've built your sprint burndown chart, the real skill is knowing what the line shape is telling you. Three patterns show up repeatedly in real sprints, and each one demands a different response.

Line above the ideal (team is behind)

The actual line sits above the ideal line and the gap widens as the sprint progresses. Work is being completed, but slower than planned. This usually means the team underestimated story complexity, someone is blocked and the blocker hasn't surfaced yet, or capacity was overcommitted. The action: bring it to the next standup, identify the specific stories causing the drag, and decide whether to descope or pull in help before the sprint ends.

Flat line (work is blocked or not being logged)

The remaining work stops decreasing for two or more consecutive days. Either tasks are genuinely stuck, or team members are completing work without updating the board. Both are problems. A flat line that lasts past day two is a signal to identify which stage is causing the blockage rather than wait for the sprint retrospective to surface it. Ask in standup: "What would it take to move this today?"

Steep late drop (work was batched, not done incrementally)

The line stays flat or barely moves for most of the sprint, then drops sharply in the final two days. This looks like success on the last day but masks a real problem: work was completed in a batch rather than incrementally. It makes sprint forecasting unreliable and hides integration risk. The fix is a process one, not a planning one. Review how tasks are being broken down and logged. If stories are only marked done when fully deployed rather than when individually completed, that's where the batching starts.

For context on how these patterns map to a full sprint cycle, the step-by-step walkthrough of building an agile burndown chart covers the setup decisions that influence which pattern you're likely to see.

Benefits of Using a Burn Down Chart in Software Development

A burn down chart earns its place in a sprint ritual because it makes sprint health visible without a status meeting. Three concrete benefits explain why agile teams keep it on the wall.

Daily visibility into scope: The chart shows remaining work against the ideal line every single day. Teams catch a two-day slip on day three, not at the retrospective. Pair it with a project tracking dashboard that surfaces burn down data alongside other sprint metrics and the picture is complete before standup starts.

Early warning on scope creep: When the remaining-work line rises instead of falls, new work entered the sprint. The agile burn down chart makes that visible the same day it happens, not at the end of the sprint when recovery is harder.

A shared reference point: Developers, QA, and the product owner look at the same data. Disagreements about sprint status resolve against the chart, not memory.

For a step-by-step walkthrough of building an agile burndown chart, the mechanics are straightforward once the benefits are clear.

Tools That Generate a Burn Down Chart Automatically

Most burn down chart tools fall into two categories: general project managers that bolt on a chart view, and sprint-native tools that generate the chart from actual task data.

For a sprint burn down chart to be accurate, the tool needs to pull remaining story points or hours automatically as tasks close. If you're exporting to a spreadsheet and updating it manually, you're adding 15–30 minutes of admin per sprint day and introducing the exact human error the chart is supposed to eliminate.

When evaluating burn down chart tools, look for:

• Automatic recalculation when tasks are marked complete

• Story-point and hour-based input options (not just one)

• Mid-sprint scope change logging, so the ideal line adjusts rather than lying flat

Taro handles this natively. Its sprint tracking updates remaining effort in real time, and its story-point reporting feeds directly into the burn down view. If a flat line appears, you can identify which stage is causing the pattern without leaving the dashboard.

For broader context, pair the chart with a project tracking dashboard that surfaces burn down data alongside other sprint metrics so nothing hides between views.

Common Mistakes That Make Burn Down Charts Useless

Three mistakes consistently turn a burn down chart into a chart that lies.

Skipping daily updates is the most common. When remaining hours only get logged at sprint reviews, the line looks flat for days, then drops sharply — the opposite of useful. An agile burn down chart needs daily input to show real progress.

Marking tasks done before they meet your definition of done inflates the burn. If QA, review, or deployment steps are still pending, the work isn't done. Counting it anyway means your chart shows a healthy slope while actual completion lags behind.

Ignoring mid-sprint scope changes is the quietest killer. When new tasks get added without adjusting the baseline, the ideal line becomes fiction. Log every scope change the day it happens, and use a velocity chart to set a realistic ideal line for future sprints.

Knowing how to read a burn down chart starts with knowing whether the data feeding it is honest.

Closing

A burn down chart only works if your team reads it before the sprint ends — not after. The three deviation patterns (above ideal, flat line, steep late drop) aren't just retrospective observations; they're real-time signals that let you course-correct mid-sprint instead of explaining delays at review.

Once a team can read their burn down line, the next question is always 'where exactly is the work stuck?' That's where most teams hit a wall — they spot the flat line but lack visibility into which stage is causing the blockage. Taro's sprint tracking and bottleneck analysis answers that question without a separate investigation, so you can unblock work the same day you spot it. Start a free trial to see how your team's actual burn down compares to ideal.

FAQ