

What is the best project management software? Discover our comparison and choose the solution adapted to your project management methodology and your business.
Where Thought Leaders go for Growth
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.
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.
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 scrum methodology outlines two types of burndown charts:
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.
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:
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.
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.
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:
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.
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:
💡 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.
Before creating a sprint burndown chart or any other sprint planning tool using any software, please ensure:
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
DownloadThe 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.
Tracking progress accurately is one of the most important issues in project management. Sprint burndown charts are useful tools to keep track of the work left to do on a daily basis, during the daily scrum, as the product backlog is reviewed and updated.
They are an essential part of the scrum methodology and allow both the project manager and their team to always keep their eyes on the road ahead!