A burndown chart is one of the simplest tools in agile project management, and one of the most misunderstood. Teams create them, glance at them during standups, and then ignore the signals they provide. Or worse, they treat the chart as a performance report rather than a diagnostic tool. I have watched teams stare at a flat line for five days and not change a single thing about how they are working.
The burndown chart is not there to make you feel good or bad about your sprint. It is a feedback mechanism that tells you whether your plan matches reality. When you know how to read it properly, this chart gives you early warning signs that would otherwise surface as missed deadlines. When you misread it, you end up gaming the metric instead of fixing the problem.
I have used burndown charts on every team I have built, and the pattern is consistent. Teams that learn to read the signal properly get better at estimation, planning, and delivery. Teams that treat the chart as decoration get none of those benefits. This guide covers how to build, read, and actually use sprint burndowns to improve your delivery.
What Is a Burndown Chart
A burndown chart is a graphical representation of work remaining versus time in a sprint or project. The vertical axis shows the amount of work left (typically measured in story points, tasks, or hours). The horizontal axis shows time (days of the sprint). A diagonal line from the top-left to the bottom-right represents the ideal pace: if the team completes work evenly across the sprint, the remaining work decreases at a constant rate until it reaches zero on the last day.
The actual progress is plotted as a second line. The gap between the ideal line and the actual line tells you whether the team is ahead, behind, or on track.
That is the entire concept. It is not complicated. What makes these charts valuable is not the visualization itself but the conversation it enables. When the actual line diverges from the ideal line, the team has a concrete, visual prompt to discuss what is happening and what to adjust.
According to the 16th State of Agile report by Digital.ai, burndown charts remain one of the top five most-used agile metrics, with over 50% of respondents tracking them regularly. Their persistence across fifteen years of agile practice suggests they solve a real problem, even if many teams underutilize them.
The key distinction is between a sprint-level view and a project (or release) view. A sprint burndown tracks work within a single iteration, typically one to four weeks. A project burndown tracks work across multiple sprints toward a larger milestone. This guide focuses primarily on the sprint variant, since it is the more commonly used version and the one teams interact with daily.
"What gets measured gets managed." - Peter Drucker
That principle is why burndown charts persist despite all the criticisms of velocity tracking and story points. The chart itself is just a measurement. The management, the decision-making it enables, is where the value lives.
How to Read a Burndown Chart
Reading a burndown chart is about pattern recognition. There are five common shapes, and each tells a different story.
The healthy shape. The actual line tracks close to the ideal line, with minor daily variation. Work is being completed at a steady pace. The sprint is on track to complete the planned scope. This is what you aim for, but it is also the least common shape in practice.
The late start. The line stays flat for the first few days, then drops steeply. This usually means the team spent the first part of the sprint on setup, planning, or blocked work that did not produce visible progress. The steep drop indicates that once work started flowing, it moved quickly. The diagnostic question is: what caused the slow start, and can you eliminate it next sprint?
The stepped descent. The line drops in sudden chunks rather than gradually. This indicates that the team is completing work in large batches, perhaps because tasks are too big, or because the team is only updating the board periodically. Breaking work into smaller increments will produce a smoother decline and earlier signal when things go off track.
The flat line. The remaining work does not decrease for multiple consecutive days. This is a warning sign. Common causes include blocked work (waiting on dependencies, reviews, or external teams), scope increase (new work was added mid-sprint), or task switching (the team is working but not completing anything). A flat reading in mid-sprint is the single most important signal to act on. Waiting until the sprint review to address it guarantees a missed commitment.
The upward slope. The remaining work increases. This means scope is being added faster than work is being completed. Either new stories were pulled into the sprint, or existing stories were re-estimated upward as complexity was discovered. An upward trend is a sign that the sprint plan was based on incomplete information. It is also a signal to revisit your sprint retrospective process to understand why estimation missed the mark.
Burndown vs Burnup Charts
Burndown charts show remaining work decreasing toward zero. Burnup charts show completed work increasing toward the total scope. Both convey progress information, but they visualize it differently, and that difference matters.
The key advantage of a burnup view is that it makes scope changes visible. A burnup chart has two lines: one showing completed work (going up) and one showing total scope (potentially moving). If the total scope line moves up during the sprint, you can see exactly when and by how much. In the burndown view, scope changes are hidden. If the team completes five points but three new points are added, the chart shows a net decrease of two, which looks like slow progress rather than scope creep.
Use the burndown approach when sprint scope is fixed and you want a simple view of progress toward completion. Use burnup when scope is likely to change and you want to distinguish between slow delivery and expanding scope. For release-level tracking, burnup charts are almost always more informative because scope changes over a multi-sprint horizon are the norm, not the exception.
Many teams use both. Sprint burndowns for daily standups and release burnups for stakeholder communication. The combination gives you precision at the sprint level and scope-aware tracking at the release level.
A 2023 report from the Project Management Institute found that organizations using visual progress tracking tools (including burndown and burnup charts) are 28% more likely to complete projects within the original scope. Visualization forces accountability. When the chart is visible to the whole team, progress (or lack of it) becomes a shared reality rather than a hidden concern.
Building Your First Burndown Chart
You do not need specialized software to create one. A spreadsheet works. Here is how to build it.
Step 1: Define the scope. At the start of the sprint, sum up the total work committed. If you use story points, add the points for all stories in the sprint. If you use hours, sum the estimated hours. If you use task count, count the tasks. The unit matters less than consistency. Pick one and stick with it across sprints.
Step 2: Calculate the ideal pace. Divide the total work by the number of sprint days. If you have 40 story points in a 10-day sprint, the ideal rate is 4 points per day. Plot the ideal line from (Day 0, 40 points) to (Day 10, 0 points).
Step 3: Track daily progress. At the end of each day (or at standup the next morning), calculate remaining work. Plot this value for each day. The gap between the ideal line and the actual line is your signal.
Step 4: Discuss the gap, not the line. The chart is a conversation starter. In standup, do not just display it. Talk about why the actual line diverges from the ideal. "We are three points behind the ideal pace. What is blocking us?" is a more productive standup question than "What did you do yesterday?"
Most project management tools (Jira, Linear, Shortcut, Azure DevOps) generate these charts automatically from your sprint board. The auto-generated versions work fine for daily tracking. The manual version is useful if you want to customize the visualization or if you are tracking something the tool does not support natively.
You can use the sprint waste calculator to identify where effort is being lost within your sprint, complementing the remaining-work view with a view of work that was started but not completed.
Burndown Chart Anti-Patterns
These visualizations can be gamed, misread, or misused. Watch for these patterns.
The end-of-sprint cliff. The chart shows minimal progress for 80% of the sprint, then a massive drop on the last day or two. This usually means work is being completed throughout the sprint but not marked as done until the end. It can also mean the team is rushing to close stories before the sprint ends. Either way, the tracking is not reflecting reality in time to be useful. Fix this by updating story status daily and by breaking stories into smaller pieces that can be completed incrementally.
Point inflation. If the chart is treated as a performance metric, teams start inflating story point estimates so the visualization looks better. A story that should be 3 points gets estimated at 5. The slope looks healthy, but the actual output has not changed. Sprint tracking should measure predictability, not productivity. Make this clear to the team.
Ignoring the flat line. A flat reading for two or more consecutive days is a signal that something is wrong. Teams that treat the chart as a passive display rather than an active diagnostic tool will see flat lines and do nothing. Build a team norm: if progress stalls for two days, the next standup starts with "what is blocking us?"
Tunnel vision. The chart shows quantity of work remaining but not quality. A team can burn down all their points by cutting corners, skipping tests, or accumulating technical debt. A VersionOne survey found that 48% of agile teams cite incomplete work at sprint end as a persistent challenge, often because teams optimize for velocity metrics over delivery quality. Pair your sprint tracking with quality metrics (bug counts, test coverage, review thoroughness) to get a complete picture.
Sprint Burndown Examples
Let me walk through two real scenarios from teams I have worked with.
Example 1: The discovery sprint. A team committed to 34 story points in a two-week sprint. By Day 3, the burndown was flat. The team had discovered that the database migration they planned was more complex than expected. Rather than pretending the original estimate was still valid, they pulled three stories (10 points) out of the sprint and re-estimated the migration from 5 to 13 points. The chart reset with the new scope, and the team delivered the adjusted commitment on time. The visualization did its job: it surfaced the problem on Day 3 instead of Day 10.
Example 2: The silent overcommitment. A team committed to 50 story points, their highest ever. They wanted to prove they could deliver more. The line barely moved for the first week. Stories were in progress but nothing was reaching "done" because the tasks were too large and interdependent. By Day 7, the team had completed 8 points. They finished the sprint with 28 points completed. The burndown chart showed the problem clearly from Day 2, but nobody acted on the signal. The retrospective shifted the team toward smaller stories and more conservative commitments. The next sprint, they committed to 35 points and delivered 33.
These examples illustrate that the value of a burndown chart is not in the visualization itself. It is in the team's willingness to read the signal and respond.
"Plans are worthless, but planning is everything." - Dwight D. Eisenhower
That quote applies directly to sprint tracking. The initial plan (the ideal line) will almost never match reality. The value is in the continuous act of comparing plan to reality and adjusting. A team that updates their sprint plan based on burndown signals mid-sprint will outperform a team that rigidly sticks to the original plan every time.
According to the Standish Group's CHAOS report, only 29% of software projects are delivered on time and on budget. The teams that beat those odds are not better at initial planning. They are better at mid-course correction. The burndown chart is the instrument that makes mid-course correction possible at the sprint level.
Using Burndown Data for Better Sprint Planning
The most powerful application of sprint burndowns is not within a single sprint. It is across sprints. Historical data makes planning more accurate over time.
Velocity calibration. Track how many points the team actually completes each sprint, not how many they commit to. After five or six sprints, you have a reliable velocity range. Use that range, not aspiration, to set sprint commitments.
Pattern identification. If your charts consistently show a late start, investigate. Are sprint planning meetings too short? Is the first day of the sprint consumed by carry-over work from the previous sprint? Patterns in the shapes point to systemic issues that retrospectives should address.
Estimation accuracy tracking. Compare estimated and actual completion for individual stories across sprints. If certain types of work are consistently underestimated (database migrations, third-party integrations, UI-heavy features), adjust your estimation approach for those categories. Research by Capers Jones suggests that estimation accuracy improves by 20% per cycle when teams systematically compare estimates to actuals.
"You can't control what you can't measure." - Tom DeMarco, Controlling Software Projects
That principle is the foundation of using sprint data for planning. Without historical data on how your team actually performs, you are guessing. With six sprints of tracked velocity and burndown patterns, you are making informed decisions. The difference between guessing and deciding is the data your charts produce over time.
Commitment confidence. Historical data lets you make probabilistic statements. "Based on our last eight sprints, we complete 30 to 38 points per sprint. This sprint has 35 points committed, which puts us in the middle of our range." That is a more credible commitment than "we think we can do 35 points."
For teams looking to connect this data with broader sprint health, consider integrating with sprint planning tools that combine velocity data, team capacity, and codebase context to make planning more precise.
Glue adds a dimension that traditional sprint tracking misses: codebase-level context for the work being planned. When your progress stalls, the question is always "why?" Glue can help answer that by showing which modules the in-progress work touches, where dependencies exist between stories, and where codebase complexity may be causing slower-than-expected progress. This turns your burndown chart from a lagging indicator into a starting point for actionable investigation.
Tools and Templates
Most agile project management tools generate sprint burndowns automatically. Here is how the major options compare.
Jira provides built-in sprint reports with options to view by story points, issue count, or estimated hours. The charts update automatically based on sprint board status. Jira tracking is widely used but requires diligent board management to be accurate.
Linear offers a clean, minimal progress view focused on issue count and scope changes. Linear's approach is less configurable but more opinionated, which reduces setup effort.
Azure DevOps provides widgets for both sprints and custom queries. The configuration is flexible, allowing teams to track by effort, count, or custom fields.
Shortcut (formerly Clubhouse) generates progress charts per iteration with scope change visualization built in, similar to a combined burndown/burnup view.
Spreadsheet template. For teams not using a tool with built-in tracking, or for teams wanting a custom view, a simple spreadsheet works. Columns: Date, Ideal Remaining, Actual Remaining, Scope Changes. Chart the first three columns as a line graph. Update daily. This takes two minutes per day and produces the same signal as any automated tool.
Whatever tool you use, the chart is only as good as the data feeding it. Update story status daily. Break work into pieces small enough that progress is visible at the daily level. And treat the visualization as a diagnostic tool, not a report card.
FAQ
What does a healthy burndown chart look like?
A healthy chart shows the actual progress line tracking close to the ideal line, with minor daily variation. The line trends steadily downward, reaching zero (or near zero) by the end of the sprint. Some variation is normal and expected. The key indicator of health is not perfection but predictability: the team is completing work at a roughly consistent pace without flat stretches or end-of-sprint cliffs.
Why is my burndown chart flat?
A flat chart means remaining work is not decreasing, which typically indicates one of four issues: work is blocked by dependencies or external teams, the team is working on tasks that are too large to complete within a day or two, new scope is being added at the same rate work is completed, or story status is not being updated as work finishes. Identify which cause applies and address it immediately. A flat line for more than two days is a signal that the sprint commitment is at risk.
What is the difference between burndown and burnup?
A burndown chart shows remaining work decreasing toward zero. A burnup chart shows completed work increasing toward the total scope. The key difference is scope change visibility. In a burnup chart, the total scope is plotted as a separate line, so scope additions are immediately visible. In a burndown view, scope changes are hidden because added work increases the remaining total, making it look like the team simply slowed down. Use burndown for fixed-scope sprints and burnup when scope is likely to change.
How do you calculate burndown rate?
The rate (or velocity) is calculated by dividing the total work completed by the number of elapsed days. If the team has completed 20 story points in 5 days, the rate is 4 points per day. You can also calculate the ideal rate by dividing total committed work by total sprint days. Comparing the actual rate to the ideal rate tells you whether the team is ahead or behind pace. Track this rate across sprints to build a reliable velocity baseline for future planning.