How to create and interpret a burndown chart?

A Burndown Chart is relatively easy to create. There are many tools available to generate it from the work logged by members of the Development Team. Despite its simplicity, its interpretation can provide valuable information for the entire Scrum Team. Read this article to find out how to create and interpret a Burndown Chart.

How to create and interpret a Burndown Chart? – table of contents:

How to create a Burndown Chart?
Who is responsible for the Burndown Chart?
How to interpret a Burndown Chart?
Real and ideal Burndown Chart
Selecting the unit of measurement
Summary

How to create a Burndown Chart?

The Development Team should monitor its daily work. This is the basis not only for evaluating its effectiveness but also for improving it. And one of the simplest and proven tools for this purpose is the Burndown Chart.

You can create it manually by drawing a coordinate system on a piece of paper. On the Y-axis you need to plot the amount of work expressed in a chosen unit, for example, story points. On the X-axis, draw a scale indicating the consecutive days of the Sprint. Draw a line of the ideal sprint then mark the number of realistically completed tasks for each day. Although this solution is charming and engages the team, it is not very practical. It is also not necessarily suitable for remote teams.

Therefore, digital means of creating a Burndown Chart are much more common. Many tools for logging work on tasks distributed among Team members come with an option to automatically create a Burndown Chart. Then, all a Developer has to do is mark the start and end of work on a particular product feature, and their contribution is reflected in the Burndown Chart.

With the right tools, it is also possible to freely scale the chart. This gives an insight into the combustion not only on the level of a given Sprint but also on the scale of a quarter or the whole project.

An important factor to consider when choosing a tool for creating a Burndown Chart is its accessibility to all Scrum Team members. The visibility of the Burndown Chart to the entire Development Team is a key motivational factor. Equally important is a daily look at the line showing the work remaining to be done. Talking about burn-in during the Daily Scrum,, gets Developers thinking about the ways they work and the current state of the Product.

Who is responsible for the Burndown Chart?

The question of ownership of the Burndown Chart is somewhat controversial. On one hand, it should belong to the Scrum Master, because it is a tool to make sure that the Team is working efficiently and according to plan. On the other, it should remain in the hands of the Product Owner, because it reflects the progress towards a Product Goal that’s communicated to the Customer. What’s more, a third party to claim its ownership is the Development Team as the chart functions as its internal tool.

The Burndown Chart is an essential metric to evaluate the effectiveness of the Development Team and becomes adopted by all Scrum Team members. That’s why transparency and accessibility are crucial. However, its very purpose is to serve the Team. It is supposed to strengthen its self-organization, improve motivation, and give a real picture of the status of work on the tasks assigned to it. Therefore, in theory, each member of the Development Team can update the Burndown Chart.

In practice, however, the task of updating the Burndown Chart usually falls to the Scrum Master. This happens especially at the beginning of his work with a new Development Team when the Team Velocity is still variable and difficult to estimate. Nevertheless, it is recommended to delegate this task to one of the Developers. After all, the chart is meant to be an honest and internal measurement of the progress of the work as judged by the Developers themselves.

How to interpret a Burndown Chart?

We described the appearance of the Burndown Chart in detail in a previous article. Here we will only remind you that the X-axis shows the time left to complete the work. On the other hand, the Y-axis shows the amount of work remaining to be done.

Real and ideal Burndown Chart

To interpret a Burndown Chartt, the key factor is not only the regular plotting of the real “combustion”, i.e. the execution of tasks by the Development Team. Equally important for the picture is its comparison with the ideal combustion line drop (guideline).

By comparing the ideal burn line with the real-world reduction in work marked on the Burndown Chart, two very important parameters can be assessed. First, to see whether the work continues at the current pace, the Development Team will meet the Sprint Goal or Product Goal on time. Second, to get an idea of when the work will be completed while maintaining the current pace. In other words, the Burndown Chart shows the actual pace of the tasks, and the ideal line shows at what pace the Team should work to complete the tasks.

The Burndown Chart also allows you to determine a value called Development Team Velocity in the long run. We will devote a separate article to it. Here we will just mention that it is a value determined by the amount of work done during one Sprint.

Thanks to the fact that the Burndown Chart illustrates the comparison of an ideal burn line with a real decrease in the number of tasks, it allows you to estimate the pace of work. And thus anticipate the risk of project delays.

Selecting the unit of measurement

Team velocity is usually measured in units called story points. It defines the number of user stories that have been realized. These can require very different amounts of work.

This is why many Scrum Teams use a time-based measure. Depending on the scale, these are days or man-hours. Each Developer estimates and then logs the amount of time spent on their tasks.

Another option is to adopt tasks as a unit. These are slightly larger units, which in turn are assigned a value expressed in story points, or in days or man-hours. It is a unit that allows the client to present the progress of work on the product in a clearer way.

Regardless of the unit of measurement, it is worth remembering the principle of calculating the speed of the Development Team. In a given day or Sprint, only tasks that were actually completed, count. It means that tasks started will be counted towards the next day or Sprint even if only final testing is missing.

Summary

How to create and interpret a Burndown Chart?

With the team monitoring tools available, creating a Burndown Chart becomes an easy task. The most important issue is to ensure its coherence, clarity and accessibly to all Scrum Team members.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Author: Caroline Becker
As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.
View all posts

Maintenance break

Scrum Guide | 31. How to create and interpret a Burndown Chart?

How to create and interpret a Burndown Chart? – table of contents:

How to create a Burndown Chart?

Who is responsible for the Burndown Chart?