The Sprint Burndown Chart, an Agile Tool to Track Project Progress

By Henri Gisclard-Biondi

Published: 11 March 2021

If your company is looking to implement agile project management, the scrum methodology provides a great tool to track the progress of your projects: the sprint burndown chart.

This scrum tool allows you to visualise the progress made by the project team and helps you respect the deadlines set for the scrum project.

This guide will tell you all there is to know about the sprint burndown chart. We’ll teach you how to build your own in 4 simple steps, and provide a free Excel template, so you don’t have to start from scratch.

See all software Project Management

What is a sprint burndown chart?

A sprint burndown chart is a tool first used for agile software development, though it can be useful to any type of project, especially projects conducted using agile methodologies.

It is a graphical representation of the amount of work remaining for a set period of time, the sprint. Interpreting the burndown chart gives project managers insights into the progress made by the team. It can then be used to make forecasts regarding your goals and objectives.

Burndown charts in agile project management

How to read a burndown chart?

Though it can be used for any kind of project and business area, burndown charts are monitoring tools that often rely on elements specific to the scrum methodology and are at their best when used in agile project management.

As a rule, the chart has two axes:

The horizontal axis (X-axis), which represents the time needed to complete the project. It can be expressed in any unit of time but is usually the number of days of the sprint
The vertical axis (Y-axis), which represents the amount of work remaining. An easy way to translate the total workload into numbers is to use the total number of user stories expressed in story points.

Sprint burndown charts vs release burndown charts

The scrum methodology outlines two types of burndown charts:

The sprint burndown chart (also known as iteration burndown chart): the unit of time of choice is usually the number of days of the sprint, as each iteration or development cycle lasts between 2 and 4 weeks
The release burndown chart: sprints are used as the unit of time. It is useful in the case of projects lasting longer than one sprint, in other words, if the total development cycle is longer than a couple of months.

A burndown chart to estimate the workload remaining after each iteration

The example shown above is a release burndown chart: the X-axis features each iteration and the total number of story points remaining to be done during each sprint.

A sprint burndown chart could be built for each sprint to view project progress in detail: it would show the number of user points completed daily during the sprint. Imagine zooming into each bar of the chart shown above and adopting a day-by-day view.

How to create your burndown chart in 4 steps

1. Set your goals

The first step to creating your burndown chart is to identify an objective to reach and the actions you’ll need to take in order to achieve this goal.

In other words, you should set a concrete objective for your project. What do you want to improve, achieve or create? A precise goal will give you a solid vision and will ensure you won’t get sidetracked along the way and end up with poor results or irrelevant product.

Get in touch with your client or end-user to make sure you’ve understood their needs and are aware of all the requirements related to your project. You can use SMART criteria to assess the quality of your objectives. They should be:

Specific to the project
Measurable with readily available KPIs
Achievable by the development team in the timeframe
Relevant to your or your clients’ needs
Time-bound: set a deadline for the completion of your project

Once you’ve determined your main objectives, try to think of the actions you will need to take to reach them. This will give you a basis for breaking down your project further into specific tasks to complete.

2. Break down the project into tasks and estimate the workload

This step aims at subdividing the actions that will help you reach your goals into specific tasks the project team will then complete. These tasks should be concrete, specific, and be associated with a quantifiable workload, expressed in working hours, days or points.

In the case of software development, these tasks can take the form of product backlog items, which are features that need to be integrated into the final product.

These features are described by user stories, which are real-life examples of use case scenarios performed by characters or personas with specific characteristics to represent relevant types of end-users. Each story is then assigned a different number of story points which are a representation of the amount of work needed to implement the feature.

☝️ Methods such as the planning poker can be used to estimate the number of points that would best represent the workload of each task or user story.

As a rule, feel free to discuss with team members to estimate the workload and think of which tasks would need to be done together.

3. Build the chart

Now that this preparatory work is complete, it is time to build the burndown chart. As we’ve seen, this means representing the progress of your sprint or project using two axes:

A horizontal axis for time (days in the case of a sprint burndown chart, sprints in the case of a release burndown chart)
A vertical time to represent the remaining workload (using story points or working hours)

As the burndown chart is used to visualise the amount of work that remains to be done, the starting point isn’t 0 but all the way up the Y-axis. If the total workload is estimated to be 160 story points or working hours, then the graph will start at 160. The goal is to reach 0 with a line graph going down.

4. Finalise and analyse the burndown chart

Each day during the daily scrum, the scrum master or product owner will review and update the number of tasks left to complete in the sprint backlog. They can add or remove tasks based on events that have occurred during the development.

This information is then fed into the burndown chart to give a real-time representation of the progress left to make. Using Excel, for example, you could fill out a table to generate a line chart.

To compare the ideal progress line to the actual progress chart:

Start by tracing a line to represent the ideal progress of your sprint or project. It could be a straight line from the top to 0 to represent an equal distribution of the workload throughout the course of the sprint.
Trace the line representing your actual progress in another colour to have more visibility over how the two compare, meaning if you’re ahead of behind schedule.

Trello provides a tool to compare actual progress with the ideal line for each sprint

💡 In general, at the start of the project, the team will likely be behind schedule, meaning above the ideal progression line. This is because they need time to be fully operational: after the first few weeks or days, they will probably catch up and complete the sprint goal in time thanks to an increase in efficiency during the late stages of the sprint.

Free sprint burndown chart Excel template

Before creating a sprint burndown chart or any other sprint planning tool using any software, please ensure:

Workloads and allotted time are consistent. If deadlines are set arbitrarily, it will be difficult to estimate how much time was lost or gained relative to the objective.
The product backlog (list of remaining tasks) is updated daily. It should give a real-time snapshot of the remaining work.

To build a burndown chart without breaking a sweat, you can use our free sprint burndown chart template in Excel format. Customise it to your project and start tracking progress right away:

Download your Burndown chart

Download

What about the burn up chart?

The burn up chart is also one of the most useful tracking tools in project management. This one is the mirrored view of the burndown chart: it shows the progress already accomplished by the scrum team.

Depending on the way you want to present reports of your current progress, you can choose from either graph. A rule of thumb is that the burndown chart gives better visibility over the course of a sprint, whereas burn up charts provide a more useful view of the project as a whole.