What is a burndown chart? How to create and interpret one

A sprint can feel productive while still falling behind schedule. Developers are completing tasks, code reviews are moving forward, and standups suggest steady progress. Yet, as the deadline approaches, the team discovers that a significant amount of work remains unfinished. Without a clear view of the remaining workload, these gaps can be difficult to recognize early.

A burndown chart helps teams understand how much work is left and whether progress aligns with the available time. Widely used in Agile project management, it provides a visual reference for monitoring sprint execution and identifying potential delivery risks.

This guide explains how burndown charts work, their different types, how to create and calculate one, and how to interpret progress patterns using practical examples.

What is a burndown chart?

A burndown chart is a graphical representation of the amount of work remaining in a project, sprint, or release over a defined period. It plots unfinished work against time, allowing teams to compare actual progress with the planned rate of completion.

In Agile project management, burndown charts help teams monitor how their workload changes as development progresses. The remaining work is typically measured using story points, task counts, or estimated hours, depending on the team's estimation approach.

A burndown chart in Scrum is commonly associated with sprint execution. Teams use it to understand whether the work selected for a sprint is progressing toward completion within the available timeframe. Although burndown charts are widely used in Scrum environments, the framework does not require teams to use them.

For example, consider a development team beginning a two-week sprint with 40 story points of planned work. As work items are completed, the chart reflects the reduction in outstanding story points. The resulting trend helps the team assess its progress and investigate potential delays before the sprint ends.

How does a burndown chart work?

A burndown chart works by showing how the amount of unfinished work changes throughout a sprint or project. It compares the team's expected progress with actual work completed, helping teams understand whether they are moving toward their planned deadline.

Here's how it works:

1. Start with the total planned work: At the beginning of a sprint, the team records its estimated workload, usually agreed upon during sprint planning. For example, a 10-day sprint might begin with 40 story points.
2. Establish the expected progress: An ideal burndown line shows how the workload would decrease if work were completed at a steady rate throughout the sprint.
3. Track actual work completion: As work items are completed, the team updates the remaining workload. These updates form the actual burndown line, showing how progress changes over time.
4. Compare progress against the plan: If the actual line stays above the ideal line, more work remains than expected. If it falls below, less work remains than planned. Teams can investigate these differences and adjust their approach when necessary.

As the actual line approaches zero, the tracked workload moves closer to completion. This gives teams a shared view of delivery progress and helps them identify potential delays during the sprint.

What are the key components of a burndown chart?

A typical burndown chart contains five components that collectively explain the relationship between remaining work and time.

1. X-axis (time)

The horizontal axis represents the project's duration. For a sprint burndown chart, it typically shows individual working days. Longer-term charts may use weeks or sprint intervals. The axis establishes how much time has passed and how much remains before the target completion date.

2. Y-axis (remaining work)

The vertical axis measures the unfinished workload. Teams can express this using story points, work item counts, or estimated effort. The chosen unit determines what changes in the chart actually represent. For example, a five-point reduction on a story-point chart means that five points of estimated work have been completed or otherwise removed from the remaining total.

3. Ideal burndown line

The ideal line represents a reference trajectory for completing the initial workload within the available time. It usually appears as a straight descending line connecting the starting workload to zero at the deadline. This assumes a constant rate of completion for comparison purposes, even though actual work rarely progresses evenly.

4. Actual burndown line

The actual line shows the recorded amount of work remaining throughout the sprint. Its shape changes as work items are completed, estimates are revised, or scope is adjusted. Comparing it with the ideal line helps teams recognize differences between expected and actual progress.

5. Starting point and endpoint

The starting point indicates the initial amount of planned work, while the endpoint represents the intended completion date and remaining-work target. Together, these points define the baseline used to evaluate progress.

What are the different types of burndown charts?

Burndown charts can track work across different planning horizons. The underlying measurement remains consistent, while the scope and reporting intervals change according to what teams need to monitor.

1. Sprint burndown chart

A sprint burndown chart tracks work remaining within a single Agile sprint. It typically uses daily reporting intervals and helps teams assess progress against their sprint plan.

For example, a team working on authentication improvements might use a sprint burndown chart to monitor the remaining estimated effort for login changes, password recovery, and related testing. The chart helps identify whether the selected work is likely to be completed within the sprint.

2. Release burndown chart

A release burndown chart measures remaining work across multiple sprints leading to a planned software release. Its timeline often uses sprint intervals rather than individual days.

Engineering and product teams use this chart when coordinating features, fixes, and other deliverables that must be completed before a release. It provides a broader perspective on progress and helps teams evaluate potential changes to release scope or timing.

3. Epic burndown chart

An epic burndown chart tracks the work associated with a larger feature or initiative that contains several related work items.

For instance, an epic covering a new billing system might include subscription management, invoice generation, payment handling, and reporting capabilities. An epic burndown chart helps teams monitor progress across these components, even when the work spans multiple sprints.

4. Project burndown chart

A project burndown chart tracks remaining work across a defined project timeline. It can support initiatives involving several teams, milestones, or delivery phases.

Project managers can use this broader view to monitor outstanding work and identify areas that require additional attention. Its usefulness depends on maintaining consistent estimates and clear scope boundaries across the project.

The following table summarizes the differences:

These categories describe common applications rather than a universal classification. Teams can adapt burndown charts to different scopes depending on their planning practices and reporting needs.

How do you calculate a burndown chart?

A burndown chart calculation begins with the total estimated workload and the amount of time available to complete it. Teams use these values to establish an ideal trajectory and compare it with the work remaining during execution.

Calculate the total estimated work

Start by identifying the work items included in the sprint and estimating their combined workload.

Suppose a development team plans a sprint with the following work:

The sprint begins with 40 story points of estimated work. This becomes the starting value for the burndown chart.

Story points represent a team's relative estimates of work, often considering effort, complexity, and uncertainty. Their values should be interpreted within that team's estimation system.

Calculate the ideal daily burndown rate

The ideal daily burndown rate indicates how much work would need to be completed each working day to reduce the initial workload to zero at a constant pace.

Formula:

Ideal daily burndown rate = Total estimated work ÷ Number of working days

For a sprint containing 40 story points over 10 working days:

Ideal daily burndown rate = 40 ÷ 10 = 4 story points per day

The ideal remaining work at the end of any working day can then be calculated as:

Ideal remaining work = Initial estimated work − (Ideal daily burndown rate × Days elapsed)

For example, after five working days:

Ideal remaining work = 40 − (4 × 5) = 20 story points

This establishes the reference line for the chart. The actual rate will vary as work items reach completion at different times.

Calculate the actual remaining work

For a chart based on completed story points, the remaining workload can be calculated using:

Remaining work = Current total scoped work − Completed work

If the team has completed 19 story points from an unchanged 40-point sprint scope, the actual remaining work is 21 story points.

When new work is added, existing work is removed, or estimates are revised, the total scoped workload must be adjusted accordingly. These changes can influence the burndown even when the amount of completed work remains unchanged.

For charts based on estimated remaining hours, teams may update the outstanding effort directly as their understanding of the work improves. In that case, elapsed hours and reduced remaining effort are not necessarily equivalent.

How do you create a burndown chart? A step-by-step guide

Creating a burndown chart requires a clearly defined workload, a consistent measurement approach, and reliable progress updates. The following process applies to teams using spreadsheets as well as Agile project management tools.

Step 1: Define the sprint scope and timeline

Identify the work that the team plans to complete during the sprint. Establish the sprint goal, start date, end date, and reporting intervals.

For the example above, the team has selected 40 story points of work for a 10-working-day sprint. These values establish the initial scope and timeline.

It is also important to determine how scope changes will be recorded. Without this information, later changes in the remaining workload can be difficult to explain.

Step 2: Choose a unit for measuring work

Select a consistent measurement unit for the chart. Common options include story points, task counts, and estimated hours.

Story points are useful when teams estimate backlog items using relative effort. Task counts offer a simpler approach but treat each task equally regardless of its size. Estimated hours can provide an effort-based view when teams regularly maintain their remaining-time estimates.

Choose a unit that matches the team's existing planning practices and apply it consistently throughout the reporting period.

Step 3: Estimate the total work at the start

Calculate the combined workload of the items selected for the sprint.

If the team uses story points, add the estimates assigned to its planned work items. For task-based tracking, count the items included in the sprint.

Record this value before execution begins so that the team has a clear reference for understanding subsequent changes.

Step 4: Plot the ideal burndown line

Create a chart with time along the horizontal axis and remaining work along the vertical axis.

Mark the initial workload at the beginning of the sprint and zero remaining work at the planned completion date. Connect these points to establish the ideal burndown line.

For the 40-point example, the reference line decreases by four story points at each working-day interval.

Step 5: Record actual work completed

Track work item completion throughout the sprint and calculate the remaining workload at the end of each reporting interval.

A work item should generally be counted as completed only when it satisfies the team's agreed completion criteria. Work that is still undergoing implementation, testing, or review remains unfinished until those criteria are met.

Record scope changes separately so that increases or decreases in the workload can be understood later.

Step 6: Plot and update the actual burndown line

Add the recorded remaining-work values to the chart and connect them in chronological order.

Teams creating a chart manually can use a spreadsheet with columns for the reporting day, ideal remaining work, and actual remaining work. A line chart can then visualize both series.

A burndown chart template in Excel or Google Sheets can simplify this setup, while supported Agile project management tools can generate charts from tracked work item data.

Step 7: Review the chart throughout the sprint

Review the updated chart at a regular cadence to understand whether the current workload and available time remain aligned.

When the actual trajectory differs significantly from the initial plan, investigate the contributing factors. The team may need to address a blocker, adjust its execution approach, or discuss scope with the product owner.

The objective is to use the chart while there is still time to make informed adjustments.

What does a burndown chart look like? A practical example

Consider the same development team working through a 10-day sprint with 40 story points of initially planned work.

The ideal trajectory assumes four story points are completed each working day. In practice, some work items require several days before they meet the completion criteria, creating an uneven pattern of recorded progress.

The following example uses an unchanged sprint scope and tracks the remaining story points at the end of each day.

Several observations emerge from this burndown chart example.

During the first few days, the team completes work more slowly than the ideal reference line suggests. By Day 5, 27 story points remain against an ideal value of 20. The actual line remains flat between Days 4 and 5, indicating that no additional story points were recorded as completed during that interval.

Progress improves during the second half of the sprint. By Day 8, the remaining workload has decreased to 11 story points, and the team continues completing work over the final two days.

At the end of the sprint, two story points remain unfinished. The team has completed 38 of the initially planned 40 story points.

The chart establishes how the remaining workload changed throughout the sprint. To assess the delivery outcome, the team would also review which work item remained unfinished, whether the sprint goal was achieved, and what influenced the completion pattern.

How do you read and interpret a burndown chart?

Reading a burndown chart involves examining the relationship between the actual and ideal progress lines, along with changes in the actual line's direction and slope.

For teams learning how to read a sprint burndown chart, the most useful approach is to identify the visible pattern, investigate what caused it, and determine whether any action is necessary.

1. Actual line closely follows the ideal line

When the actual line stays near the ideal line, the amount of remaining work is decreasing at approximately the expected rate.

This pattern suggests that the sprint is progressing broadly in line with its original plan. Small fluctuations are normal because work items differ in size and completion timing.

What teams should do: Continue monitoring the work that remains, especially complex items and dependencies that could affect completion. The chart provides a useful progress signal, while the sprint backlog offers the detail needed to assess delivery risk.

2. Actual line stays above the ideal line

An actual line above the ideal line means more work remains than the reference trajectory anticipated at that point.

Possible explanations include longer implementation times, unresolved dependencies, underestimated complexity, or changes in scope.

For example, if the ideal remaining workload is 16 story points but the team still has 23 points outstanding, the seven-point difference warrants closer examination.

What teams should do: Review the unfinished items, identify work that is unlikely to be completed within the remaining time, and address constraints affecting progress. If the sprint goal is at risk, the team should discuss appropriate adjustments.

3. Actual line falls below the ideal line

When the actual line moves below the ideal line, less work remains than the planned trajectory suggests.

This can happen when several work items are completed earlier than expected, estimates prove conservative, or previously planned work is removed from scope.

What teams should do: Confirm that recorded completions meet the agreed quality criteria and review any scope changes. If the work is genuinely progressing faster than expected, the team can use the additional capacity to strengthen testing, address relevant technical work, or refine upcoming backlog items.

4. Actual line stays flat

A flat line indicates that the recorded amount of remaining work has not changed during the reporting interval. In a story-point-based chart, this can occur even when developers are actively working. Several work items may be progressing simultaneously without any reaching completion.

A prolonged plateau can also indicate blocked work, large backlog items, or incomplete status updates.

What teams should do: Inspect work in progress and determine whether individual items are moving toward completion. If work remains unfinished for extended periods, consider whether items should be broken into smaller, independently valuable units during backlog refinement.

5. Actual line drops sharply

A sharp downward movement indicates that a substantial amount of work was recorded as completed within a short period. This pattern can appear when multiple work items finish together, a large item reaches completion, or the team updates several previously completed items at once.

For example, a line decreasing from 24 to 12 story points in one day may reflect several items clearing final testing or review.

What teams should do: Check whether the change reflects actual completion timing or delayed updates. If substantial progress consistently appears near sprint deadlines, investigate how work moves through development, review, and testing.

6. Actual line moves upward

An upward movement indicates that the recorded amount of remaining work has increased.

This can occur when additional work is introduced, estimates are increased, or previously completed items are reopened. For example, adding an eight-point requirement without completing other work would increase the remaining workload by eight points.

What teams should do: Identify the change that caused the increase and assess its impact on the sprint goal. Record significant scope adjustments and discuss whether the updated workload remains achievable.

When learning how to interpret a burndown chart, the following reference can help connect common patterns with their implications.

These patterns become more useful when examined alongside work item status, team discussions, and delivery context. A single point on the graph rarely provides enough information to explain the underlying situation.

Why are burndown charts important in Agile project management?

Burndown charts help Agile teams connect daily execution with their broader delivery plans. By making the remaining workload visible, they support several activities involved in managing sprints and iterative development.

1. Make sprint progress visible

A burndown chart provides a shared representation of outstanding work throughout the sprint. Engineering managers, developers, and product managers can use the same progress view without manually combining individual status reports.

This visibility is especially useful when work is distributed across multiple contributors and completion depends on coordinated delivery.

2. Identify potential delays earlier

Comparing remaining work with the available time helps teams recognize emerging delivery pressure.

When unfinished work accumulates, teams can investigate the contributing factors while there is still an opportunity to resolve dependencies, improve coordination, or reconsider the remaining scope.

3. Support daily standups and team discussions

As a sprint progress chart, a burndown provides a useful reference during discussions about current execution.

Teams can use changes in the chart to decide which work items require attention and whether their approach for the coming days needs adjustment. This helps keep conversations grounded in the sprint's current delivery situation.

4. Improve future sprint planning

Historical burndown charts help teams reflect on how their initial plans compared with actual completion patterns.

For example, repeated unfinished work at the end of several sprints may suggest that the team is selecting more work than its available capacity supports. These observations can inform future scope selection, estimation discussions, and dependency planning.

5. Strengthen delivery transparency

Product stakeholders often need to understand progress without reviewing every engineering work item.

A burndown chart provides a concise view of remaining work that can support conversations about delivery expectations. When combined with explanations of scope changes and outstanding risks, it helps teams communicate their current position more clearly.

6. Support sprint retrospectives

Burndown trends provide useful evidence for evaluating how work progressed during a sprint.

Teams can examine periods of limited completion, changes in workload, and unusually concentrated delivery activity. These observations can guide discussions about work item sizing, review processes, testing practices, and other improvements to the development workflow.

What is the difference between a burndown chart and a burnup chart?

Burndown and burnup charts both help Agile teams visualize delivery progress, but they organize the information differently.

• A burndown chart displays the amount of work remaining over time. As work is completed, its progress line generally moves downward toward zero.
• A burnup chart displays completed work over time, typically alongside a separate line representing the total scope. Its completed-work line generally moves upward as delivery progresses.

The distinction becomes especially useful when project requirements change during execution.

When should teams use each chart?

A burndown chart is useful when the team wants to monitor how much work remains within a defined delivery period. It is particularly practical for sprint-level tracking where the planned workload is relatively stable.

A burnup chart is helpful when requirements change frequently or stakeholders need a clearer distinction between completed work and total planned scope.

For example, a product team developing a new analytics dashboard may complete several planned features while additional requirements are introduced. A burnup chart can display the increase in completed work alongside the expanding scope, making these two developments easier to distinguish.

Teams can use both visualizations when they need visibility into short-term execution and broader delivery changes.

What are the common limitations and mistakes when using burndown charts?

Burndown charts provide a simplified view of delivery progress. Their accuracy and usefulness depend on the quality of the underlying information and how teams interpret it.

The following mistakes can reduce the value of burndown tracking.

1. Treating the ideal line as a fixed performance requirement

The ideal line assumes that work will be completed at a constant rate. Actual software development involves varying task sizes, reviews, testing, and dependencies that affect when work reaches completion.

Expecting the actual line to follow a perfectly straight trajectory can create unrealistic performance expectations.

Best practice: Use the ideal line as a planning reference. Evaluate deviations based on their causes and potential effect on the sprint goal.

2. Using inconsistent estimation units

A chart becomes difficult to interpret when the team changes measurement methods or combines incompatible units.

For example, a team measuring story points at the beginning of a sprint cannot directly interpret later task-count values on the same scale.

Best practice: Define the measurement unit before tracking begins and use it consistently. If the estimation approach changes, establish a new baseline and explain the change.

3. Failing to update work item information regularly

Outdated work item statuses and estimates can cause a burndown chart to misrepresent the current workload.

When updates are postponed, the resulting chart may show extended periods of inactivity followed by large reductions that reflect reporting delays.

Best practice: Establish a consistent update process and ensure that completion statuses accurately reflect the team's agreed definition of done.

4. Ignoring changes in sprint scope

Work can be added, removed, or re-estimated after a sprint begins. These changes affect the remaining workload and may distort comparisons with the initial plan.

A chart that shows an increase in unfinished work offers limited explanatory value unless the team can identify the scope changes responsible.

Best practice: Maintain a record of significant additions, removals, and estimation changes. Use that information when evaluating delivery trends.

5. Using burndown charts to measure individual performance

Burndown charts reflect work completion within a defined scope and reporting period. They provide limited information about the contributions of individual team members.

Software development frequently involves collaboration, shared dependencies, technical investigation, and supporting work that cannot be reliably attributed through a single progress line.

Best practice: Use burndown charts for team-level planning and coordination. Evaluate individual contributions through appropriate qualitative and role-specific measures.

6. Relying exclusively on burndown charts

A burndown chart can show zero remaining work even when important delivery concerns require further examination.

For example, completed work may still need deployment, operational validation, or other activities outside the chart's defined scope. The chart also cannot independently explain customer value, engineering quality, or workflow bottlenecks.

Best practice: Review burndown data alongside relevant measures such as sprint goal achievement, work item status, cycle time, escaped defects, and delivery outcomes.

How can Plane help teams track sprint progress with burndown charts?

Plane helps engineering and product teams organize sprint work, monitor execution, and understand delivery progress within a shared project management workspace.

With Cycles, teams can organize work items into defined sprint periods and monitor their progress using built-in burn-down and build-up charts.

Plane's burn-down charts visualize the remaining workload against an ideal progress trajectory, helping teams understand whether execution is leading or trailing the expected pace. Teams can measure progress using work item counts or point estimates, depending on their preferred estimation approach.

Cycle summaries also provide visibility into completed and pending work items, remaining days, and overall progress. These views give teams useful context when reviewing their delivery plans and identifying work that needs attention.

By keeping sprint planning, work item tracking, and progress reporting in one place, Plane makes it easier to connect burndown trends with the work behind them.

Explore Plane's Cycles to plan sprints and track work as it progresses.

Conclusion

Burndown charts give Agile teams a practical way to understand how their remaining workload changes throughout a sprint, release, or project. With accurate estimates, consistent updates, and regular review, they help teams recognize delivery patterns and make better-informed planning decisions.

The most useful insights come from understanding the reasons behind changes in the chart. Teams that connect progress trends with scope, dependencies, and completion criteria can use burndown charts to improve coordination and develop more realistic delivery plans.

Frequently asked questions

Q1. What is the purpose of a burndown chart in Scrum?

A burndown chart in Scrum helps teams visualize how much work remains during a sprint and how that workload changes over time. It supports progress monitoring and helps identify potential delivery risks. Scrum teams can use it to inform planning discussions and evaluate whether their current approach supports the sprint goal.

Q2. How often should a burndown chart be updated?

A sprint burndown chart is typically updated daily so that teams can review recent progress using consistent reporting intervals. Updates should reflect completed work and relevant changes in scope or estimates. Agile project management tools may refresh chart data automatically as tracked work items are updated.

Q3. Can a burndown chart show an increase in work?

Yes. A burndown chart can move upward when the recorded remaining workload increases. This may happen when new work items are added, existing estimates increase, or completed items are reopened. Teams should investigate these changes to understand their effect on the delivery plan.

Q4. What happens if a burndown chart does not reach zero?

If a burndown chart does not reach zero by the planned completion date, some work included in the chart remains unfinished. The team should identify the outstanding items and determine how they will be handled. In Scrum, the sprint goal may still have been achieved even if some initially selected work remains incomplete.

Q5. What is the difference between a burndown chart and a velocity chart?

A burndown chart tracks how much work remains during a sprint or another defined period. A velocity chart typically shows the amount of estimated work a team completed across successive sprints. Teams often use velocity history to inform future sprint planning, while burndown charts help monitor work during execution.