How to create and use a burn chart

A burn chart shows a quick visualization of whether a project is on track, which can make it a helpful tool in project management. 

A burn chart is a visual project management tool that can track a project’s progress over a defined period, such as a project phase or sprint. The horizontal axis typically represents time, and the vertical axis often represents units of work. Those units might be measured in story points, tasks or hours depending on the team’s approach.

The charts may be associated with agile frameworks such as Scrum, which break down larger projects into smaller phases. That said, any project with a defined set of tasks and a clear timeline could potentially benefit from this type of visual tracking. 

There are two common variants. A burn down chart tracks work remaining; it starts high and ideally trends toward zero by the end of the period. If the graph trends upward rather than downward, it’s sometimes called a “burn up chart.” Both types track the total work completed against the full project’s workload, which can make scope changes more visible. Both options can serve a similar purpose, but the burn up version may be more useful when scope is expected to shift during the project.

A useful burn chart should involve several core elements to effectively track progress and identify potential problems, like delays, early:

• Time axis: The horizontal axis represents the length of the project or spring, broken into a time unit like weeks or months.
• Work axis: The vertical axis represents the total units of work, which may be measured in metrics such as hours, tasks or story points.
• Ideal line: A straight diagonal line from the starting work total to zero in a burn down, or from zero to the total scope in a burn up, demonstrates the pace required for on-time completion.
• Actual line: A plotted line shows real progress each day, which can be compared against the ideal line to gauge whether the team is ahead, behind or on track.

Adding milestones, data labels and trend lines may also improve clarity by providing key information.  

Creating the chart can start with a few baseline inputs. Here’s how to create one:

1. Define the time period, such as a project phase or sprint timeline.
2. Determine the total amount of required work and choose a specific metric for measurement, such as story units or tasks.
3. Draw the ideal line from the starting total to zero for a burn down or from zero to the total for a burn up.
4. At the end of each work period, record how much work remains or how much work has been completed.
5. Plot the actual line alongside the ideal line; the difference between the two can help indicate whether the team is ahead, behind schedule or on track.
6. If scope changes occur, update and note the adjustment on the chart, as documentation on why scope changes occur can help the team make more accurate plans when defining project scope. 

Reading the chart involves comparing the actual line against the ideal line and looking for patterns.

Fortunately, the charts are typically easy to understand once users are familiar with the patterns. Here’s how to interpret them:

• Actual line below the ideal line: The team may be ahead of schedule.
• Actual line above the ideal line: The team might be behind schedule and may need to adjust resources or priorities.
• Flat sections: Work wasn’t completed during that time period, which may indicate a blocker.
• Sudden drops: A significant amount of work was removed or completed all at once, which might indicate a scope reduction or a completed milestone.
• Upward movement: Work was added, which might indicate scope creep.

Short-term fluctuations may not be meaningful on their own. A single day on which the actual line moves above the ideal line doesn’t necessarily indicate a problem. For example, it could just mean that a task took longer than estimated but was still completed.

Looking at trends over a longer period may provide a more reliable picture than reacting to individual data points because it can help show a big picture of how a team is working and how a project is progressing. 

Burn down graphs can be useful reference points during daily stand-ups, sprint reviews and retrospectives. During a stand-up, the chart may help a team quickly assess whether it is on pace without reviewing each task individually. For example, if the actual line has flattened during the last week, the team can focus on identifying the cause of delays. During a sprint review, the chart can provide a visual summary of how the sprint unfolded, including scope changes or blockers that affected progress.

Keeping the chart accurate may become the responsibility of just one or two team members, such as a Scrum master or the person responsible for updating the project tracking tool. Consistent updates are important, since gaps in the data may make the chart harder to interpret. If updates happen only at the end of the sprint, the chart may not reflect midsprint blockers or reprioritizations that affected the team’s pace.

Burn down graphs can also complement other agile metrics. Pairing it with a velocity chart, for instance, may help teams identify whether their capacity estimates are consistently too high or too low across multiple project phases.  

A few best practices can help teams get more value from their charts. 

Keeping the underlying data clean and current can make the difference between a chart that drives decisions and one that’s ignored.

Updating the chart at the end of each day, rather than waiting until the sprint ends, can help surface patterns early and keep the visual useful as a real-time tracking tool.

Using consistent units throughout the sprint can also help keep data easy to understand and reliable. Switching between measurement types midsprint can distort the lines and make the chart harder to interpret.

Finally, tracking scope changes is equally important. If new work is added without updating the chart, the actual line may appear on track when the team is actually behind.

How the chart looks and how the team reads it can matter just as much as the data behind it.

Limiting the chart to two or three lines may be easier to understand quickly compared to adding multiple data series, colors or annotations. And when interpreting the chart, looking at multiday trends rather than reacting to a single spike or dip can provide more reliable information.

It’s also often useful to pair the chart with an actual discussion about a project’s process. The chart can show progress and the pace of work, but it doesn’t fully explain why the team is ahead or behind. The chart may show that the team is behind schedule, but it may be because leadership required a pause to shift to a more urgent priority for a week or because they significantly increased the project’s scope. Discussions can provide invaluable context moving forward. 

A basic burn down chart template might use the following column structure:

In this example, the team started a 10-day sprint with 50 story points. The ideal line drops by five points per day, and the actual line would trail behind, and a scope change on day five added four points of new work.

Plotting both columns as line charts on the same graph produces a burn chart. For teams just starting out, a simple spreadsheet with a line chart can be enough to establish the habit before investing in more specialized tools.

A standard burn down chart may not be the right tool for every situation. For teams focused on workflow efficiency rather than sprint progress, a cumulative flow diagram or a kanban board may provide more relevant information. Choosing the right visual depends on what the team needs to track, whether using Kanban or Scrum practices, and what decisions the chart is meant to support.

If you’re considering education in business or project management where you would use tools like a burn chart, University of Phoenix offers business programs, including an undergraduate Project Management Certificate.

For more information, contact University of Phoenix.