Why does our burndown chart look strange?

Posted May 11, 2022

Our burndown chart looks strange – why is it happening? Discover what is a burndown chart and what are some of the reasons why it might look strange.

According to the Scrum practices, Burndown chart is a visual measurement tool with an agile methodology that presents the work completed per day in relation to the projected conclusion tax.

The graph was created in 2000 by Ken Schwaber for the Scrum community, being that it was first used to manage software projects.

The Burndown chart demonstrates the team’s performance by comparing what was planned to what was delivered. Through this graph, it is possible to verify if the team is ahead or behind the schedule. This is critical to take the necessary steps for adaptation, if necessary.

The graph has an X-axis that represents time, which can be measured in days, weeks, and sprints, among others. While the Y-axis demonstrates the planned delivery, which can be during working hours or story points.

This graph will have an ideal line that represents a time delivery target that will decline over time and a line that will represent the team’s actual delivery. The closer the delivery line is to the ideal line, the better the team’s planning/execution. The further away or with greater variations, it means that there were problems during the sprint that compromised the delivery.

The progress tax of the Scrum team is called “speed”, which will provide a certain number of points in the history completed per iteration. In this case, the Burndown chart will measure the progress of the Sprint.

The Burndown chart will help the scrum team to collect the data related to time and work, which will show how the team is performing in the stories of two users of a given client, showing the effort dedicated to the total amount of work at each iteration.

This graph of productivity and speed is simple, it will help the team to power or progress at the conclusion of a Sprint, because it will track this progress horizontally. The graphical Scrum Burndown chart does not just bet or meet two deadlines, it also shows how the team is currently working with the flow of activities.[/vc_column_text]

Examples of a Burndown chart

Now, let’s see some examples of Burndown and the analysis that we can do based on the results:

The black line shows the ideal burndown line, while the orange line shows what was delivered by the team over the days. In the first situation, we see that the orange line did not reach zero, which means that the team failed to deliver what was planned.

With this, we can conclude that there were problems with this sprint, the planning may have been poorly carried out or the team may have encountered difficulties in developing the tasks that prevented delivery.

From there, it’s up to the team to meet and discuss ways to improve their delivery to reach the goal.

In the second situation, we see that the team managed to deliver what was planned. However, one day there was a big variation that moved the delivery line away from the ideal line:

This can occur for example, when the test activities are postponed to the final of the sprint, new bugs can be discovered at the end. The ideal is to adopt an agile testing approach to avoid this situation when the tests are executed during the development with automation tests and the QA is part of the planning.

In this another burndown sample, the amount of work was increased during the execution of the sprint, this can occur due to poor sprint planning, inaccurate estimation tasks and scope changes during the sprint.

The “perfect burndown chart”

In the third situation, we noticed that the delivery line was constantly close to the ideal line, this example can be a “perfect burndown” chart in a sprint or iteration. Note that in this case, we do not have scope changes and the work of the team is not varying during the execution of sprint or iteration.

See that in this example, the real development line is not far from the ideal, but if this happens, there is a possibility that the predictions made are very far from reality (with productivity both above and below ideal), or that something has happened to delay the project. In this case, it is important to seek to understand what is happening in the development of the project and adjust its deadline.

The key to the successful use of the tool is to keep it updated every day, preferably before the Daily Meeting suggested by Scrum so that it can be used as input for developers to decide what they will do today. At the end of the Sprint, dysfunctions like these can be inspected and adapted during Sprint Retrospectives (or at any time if the standard deviation is quite high).

It is important to point out that the effort scored in Burndown, resulting from Sprint Planning, should not be much higher or much lower than the Team Velocity, otherwise, the team will start the Sprint “overcapacity”.

In addition, good planning with the creation of small tasks will help the team to see the evolution of the burndown chart during a sprint or iteration.

The advantages to use a burndown chart

A Burndown Chart shows the reality of how work is progressing. Guesses are no longer needed. Of course, this is only the case if you keep the data by keeping your Burndown Chart up to date.
A Burndown Chart keeps everyone in the loop and engaged with progress or lack of progress.
A Burndown Chart helps you detect slower than expected progress. So you can identify and deal with what’s causing it before it gets out of hand and becomes a problem.
A Burndown Chart is easy to understand. Its simplicity makes it a highly effective progress tracker

The limitations to use a burndown chart

The Burndown Charts are focused on your little piece of a project and you will have no indication of scope changes in the rest of the project backlog. For example, if you’re looking at a Sprint Burndown, you won’t see scope changes in the rest of the backlog.
Burndown Charts only show the amount of work. They don’t show which user stories were completed or if they were the right stories to complete.
The usefulness of Burndown Charts is directly related to the accuracy of their estimates. Time estimates are notoriously inaccurate. Humans simply have too many cognitive biases for accurate time estimates. Story points are better because of their complexity and relative size. But estimating anything remains fraught with bias.
Burndown Charts do not tell you the reason for an increase in remaining work. It can come from adding work or increasing the remaining estimate of existing work. They also hide the effect of removing the job as it looks like the job is complete.

The Definition of Done is important to reflect a “perfect burndown”

A Definition of Done is a Scrum artifact used to ensure the quality of the product developed at each iteration (Sprint). A document, a contract between Scrum Team members and other stakeholders so that everyone understands what a “done” product means.

Using this concept, note that the burndown chart reflects the backlog that is done in the sprint. It is important that the evolution of burndown reflects on value delivery during the sprint execution and this value delivery is based on the definition of done. This usually includes the testing activities, so if the QA process is part of the done definition, during the execution of iteration even the test activities will contribute to the evolution of burndown chart.

Following an agile testing approach can contribute to finishing the backlog items during the sprint, since this approach favours not postponing the test tasks to the end of the iteration.

When tests are deferred to the end of the iteration, we typically have a changed burndown with many tasks to complete at the end of the iteration.

Ideally, at the end of the iteration, the backlog items are ready, validated and available to be presented to the PO, usually a process called Done Done Done. In this case the burndown will reflect on real delivery of value to the customer and the agile development and testing approach will show its real value.