1 Overview
A burndown chart is a simple line graph that shows how much work remains in a sprint over time. The vertical axis represents the amount of work left, often measured in story points, ideal days, or task hours. The horizontal axis represents the sprint timeline, usually days. A diagonal guide line, sometimes called the ideal line, shows what steady progress would look like if work were completed at a constant rate. The actual remaining work is plotted daily, creating a line that rises and falls as items are finished or added. The chart is not a scorecard. It does not measure individual performance, team velocity, or business value. It shows shape: whether work is being completed steadily, whether scope is changing, and whether the team is likely to finish what it committed to. Reading that shape correctly requires understanding the context in which the chart was drawn. A flat line might mean blocked work, a sudden drop might mean a large item was completed, and an upward spike might mean new work was added mid-sprint. None of those shapes automatically mean the team is doing well or poorly. The burndown chart is a conversation starter, not a verdict.
Because the chart is easy to generate and visually intuitive, it often becomes the most visible artifact in a sprint. That visibility can be helpful, but it can also invite misuse. Managers who do not attend daily coordination meetings may look only at the chart and draw conclusions that the team would not recognize. The chart cannot show why work is stuck, whether the remaining items are well understood, or whether the team is helping each other. It also cannot show whether the work being burned down is the most valuable work. A team could burn down a sprint perfectly while building something nobody needs. The chart shows shape, not performance scores. Treating it as a performance score distorts behavior, encourages gaming, and undermines the transparency the chart is meant to provide.
2 The problem this method was built to solve
Before burndown charts became common in agile software delivery, many teams tracked progress through status reports, percentage-complete estimates, and milestone reviews. Those methods often hid problems until late in a project. A team could report ninety percent complete for weeks while the remaining ten percent contained most of the risk. Stakeholders had little visibility into whether work was actually converging or simply being reported as converging. The burndown chart was built to solve that visibility problem. By plotting remaining work daily, it made the rate of progress visible. If the line was not trending toward zero, the team and its stakeholders could see that early enough to respond. The chart also supported a shift away from measuring activity and toward measuring outcomes. Instead of asking how many hours people were at their desks, the chart asked how much work remained. That shift aligned with the agile principle of working software over comprehensive documentation and with the idea that teams should inspect and adapt frequently.
The chart also addressed a coordination problem. In a time-boxed iteration, a team needs a shared sense of whether it will meet its commitment. The burndown chart gave everyone a common reference point. During daily coordination meetings, the team could look at the chart and ask what had changed since yesterday. A downward slope meant work was being completed. A flat slope meant something was blocked or underestimated. An upward slope meant scope had increased or work had been discovered. Those signals helped the team decide whether to adjust scope, swarm on a problem, or renegotiate the sprint goal. The chart was never meant to be a precise forecasting tool. It was meant to make the shape of progress visible so that the team could have better conversations and make better decisions. That purpose is still valid today, even though many teams now use other visualizations alongside it.
3 How one cycle runs, from ready to done
A typical cycle begins with a planning session where the team selects a set of product backlog items for the upcoming sprint. The team discusses each item, clarifies acceptance criteria, and estimates the effort required. The selected items become the sprint backlog. The team also agrees on a sprint goal, a short statement of what the sprint is intended to achieve. Once the sprint starts, the burndown chart is initialized with the total estimated work. Each day, team members update the remaining work based on what has been completed. Completed items are removed from the remaining total, and any newly discovered work is added. The chart is then updated to show the new remaining work. This daily update is usually done during the daily coordination meeting, where the team also discusses progress toward the sprint goal and any impediments.
As the sprint progresses, the burndown line should trend downward toward zero by the end of the time box. In practice, the line rarely follows the ideal diagonal. It may drop in steps when large items are completed, flatten when work is blocked, or spike upward when new work is added. These variations are normal and informative. The team uses them to decide whether to adjust the sprint backlog, ask for help, or simplify the work. At the end of the sprint, the team reviews the increment with stakeholders, demonstrating what was completed and gathering feedback. The burndown chart is often shown during this review to illustrate what happened during the sprint. After the review, the team holds a retrospective to discuss how the sprint went and what could be improved. The cycle then repeats with a new planning session. The burndown chart from the previous sprint is usually not carried forward; a new chart is created for the new sprint. Over time, teams may compare charts across sprints to understand their own patterns, but the primary value is within the sprint itself.
4 Roles and how they divide the work
In a Scrum-based approach, three roles are commonly defined: the product owner, the Scrum master, and the development team. The product owner is responsible for maximizing the value of the product and managing the product backlog. That includes ordering items, clarifying requirements, and deciding what should be worked on next. The product owner does not typically update the burndown chart, but they care about its shape because it affects whether the sprint goal is likely to be met. The Scrum master is responsible for helping the team understand and apply Scrum. They facilitate ceremonies, remove impediments, and coach the team on self-management. The Scrum master may help maintain the burndown chart, but the chart belongs to the team. The development team is responsible for delivering the increment. Team members estimate work, pull items from the sprint backlog, and update the remaining work as they complete tasks. They are the primary users of the burndown chart.
The division of work around the burndown chart is straightforward. The development team updates the chart daily, usually during the daily coordination meeting. The Scrum master ensures the chart is visible and that the team understands how to read it. The product owner uses the chart as one input among many when deciding whether to adjust scope or renegotiate the sprint goal. Stakeholders may see the chart during the sprint review, but they are not expected to interpret it as a performance measure. In teams that blend Scrum with Kanban practices, the burndown chart may be replaced or supplemented by a cumulative flow diagram, which shows work in progress across stages. In those teams, the roles may be less formal, but the principle remains the same: the people doing the work are the ones who update the visualization, and the visualization exists to support their decisions, not to evaluate them. When roles are unclear, the burndown chart can become a source of friction. For example, if a manager outside the team demands daily updates and treats the chart as a report card, the team may start updating the chart to look good rather than to reflect reality. That undermines the chart's usefulness and can damage trust.
5 Artifacts worth keeping
The burndown chart is one artifact among several that support agile delivery. The product backlog is the master list of everything that might be built. It is ordered by value and refined continuously. The sprint backlog is the subset of the product backlog selected for the current sprint, along with a plan for how to deliver it. The increment is the sum of all completed work at the end of a sprint, ideally in a usable condition. The definition of done is a shared understanding of what it means for work to be complete. These artifacts work together. The product backlog provides the raw material, the sprint backlog provides the focus, the increment provides the output, and the definition of done provides the quality standard. The burndown chart is a derived artifact. It is not a source of truth about what work exists; it is a visualization of remaining work over time. If the underlying data is inaccurate, the chart will be misleading.
Other artifacts may be useful depending on the team's context. A sprint goal is a short statement that gives the sprint a purpose beyond a list of items. A retrospective board captures what went well, what did not, and what the team will try next. A cumulative flow diagram shows how work moves through stages and can reveal bottlenecks that a burndown chart might miss. A release plan shows how multiple sprints contribute to a larger outcome. None of these artifacts is mandatory in every context. The key question is whether an artifact helps the team make better decisions. If a burndown chart is updated but never discussed, it is not adding value. If it is discussed but the team lacks the authority to act on what it sees, it can become a source of frustration. Artifacts worth keeping are those that are actively used. They should be simple enough to maintain and rich enough to inform decisions. Teams should periodically review their artifacts and retire those that no longer serve a purpose. Keeping a burndown chart because it is expected, rather than because it helps, is a sign that the team should revisit why it is using the chart at all.
6 Where this method breaks down
The burndown chart breaks down when it is treated as a performance score. If managers use the chart to compare teams or individuals, team members will start optimizing for the chart rather than for delivering value. They may inflate estimates to make the line look better, avoid adding newly discovered work, or split items in ways that create artificial drops. These behaviors distort the data and undermine the chart's purpose. The chart also breaks down when work is highly unpredictable. If a team is frequently interrupted by urgent requests, the burndown line may spike repeatedly, making it hard to see a meaningful trend. In such environments, a cumulative flow diagram or a simple work-in-progress limit may be more useful. The burndown chart assumes that work is estimated in a consistent unit and that the team can complete items within the sprint. If estimates are inconsistent or if items are too large to finish, the chart becomes noisy and less informative.
Another breakdown occurs when the chart is updated but not discussed. A chart that is filled in mechanically during a daily meeting but never used to make decisions is just overhead. Teams may continue to update it because it is part of their process, but it no longer serves a purpose. In that case, the team should either find a way to use it meaningfully or stop maintaining it. The burndown chart also struggles when the team lacks control over scope. If the product owner or stakeholders can add work mid-sprint without removing other work, the chart will show an upward trend that the team cannot influence. That can be demoralizing and can make the chart feel like a trap. Finally, the burndown chart does not show whether the work being completed is valuable. A team could burn down a sprint perfectly while building the wrong thing. For that reason, the chart should always be paired with conversations about value, user feedback, and outcomes. It is a shape, not a score. When teams remember that, the chart remains a useful tool. When they forget, it becomes a source of dysfunction.
7 Frequently asked questions
What does a flat burndown line mean? A flat line means that no work has been completed since the last update. That could be because the team is blocked, because the work is larger than expected, or because the team is spending time on unplanned tasks. It is a signal to investigate, not a judgment. What does an upward line mean? An upward line means that the total remaining work has increased. That usually happens when new work is added to the sprint or when the team discovers additional work that was not originally estimated. It is a normal part of complex work, but frequent upward spikes may indicate that the team is taking on too much or that the sprint scope is not stable. Should the burndown chart be shown to stakeholders? It can be shown during the sprint review as one way to illustrate what happened during the sprint. However, stakeholders should be encouraged to ask about the work itself, not to interpret the chart as a performance measure. The chart is a conversation aid, not a report card.
How is the burndown chart different from a burnup chart? A burndown chart shows work remaining over time. A burnup chart shows work completed over time, often alongside a line for total scope. A burnup chart can make scope changes more visible because the total scope line moves when work is added or removed. Some teams find burnup charts more informative for that reason. Can a team use a burndown chart without using Scrum? Yes. The burndown chart is a visualization technique, not a method. Any team that works in time-boxed iterations and estimates work can use one. However, the chart is most useful when the team has a shared goal and the authority to adjust its own work. What if the team never finishes everything in the sprint? That is common. The burndown chart will show remaining work at the end of the sprint. The team can discuss why in the retrospective and decide whether to adjust its planning, its estimates, or its definition of done. The goal is not to always finish everything; the goal is to learn and improve. What should a team do if the chart is not helping? If the chart is not helping, the team should talk about why. Maybe the chart is not visible enough, maybe it is not discussed, or maybe another visualization would be more useful. The team should feel free to adapt or replace it. The chart exists to serve the team, not the other way around.