Burndown Chart, one of the best friends to Scrum Masters

Burndown Charts are one of the simplest and most versatile agile methodology support tools.

Their sole purpose is to give anyone who comes near the team the ability to be informed in 20 seconds about what is happening with the team, where they are with their tasks in a given sprint, what pace they are going at, when they will finish, what is the amount of work that is likely to be delayed, or that will be completed earlier.

Yet, it costs virtually pennies to maintain and operate a Burndown Chart.

To run a Burndown Chart optimally, there are a few prerequisites that should be met:

• Do not change the composition of the team
• Work in fixed Sprints
• Break down the work into user stories
• Have a whiteboard where you can publicly and physically keep the Burndown Chart
• Maintain daily coordination (standup)

The X axis always shows the days of the Sprint. If we work in two-week Sprints, we need 10 notches. The amount of work undertaken is shown on the Y axis, preferably in story points. Keeping it in estimated hours is also possible, and in many places both units are used at the same time.

The first step is to draw the ideal line, which is a straight line from the top of the estimated hours or story points to the last day. Compared to the ideal curve, the amount of remaining tasks will decrease in a gradual manner. This is how the team’s progress will be shown.

A typical example:

Let’s say that on the first day we don’t finish anything yet, on the second day we complete a story but we are still above the ideal line (the distance between the ideal line and the part above it is the amount of work that, based on our current knowledge, is doubtful to be completed).

If, on the third day, the team completes more tasks and thus goes below the ideal line, it is again the distance between the two lines that will tell us how much work we can still fit into the Sprint, based on our current knowledge.

What can be read from the Burndown Chart? See the figure and point 13.

I also want to be a Scrum Master!

1. sum of estimated hours in the Sprint or sum of story points (if used)
2. work in days along the time axis
3. in the same split as the team agreed in the Sprint, in our case, 10 working days (two weeks)
4. the ideal line. If we are above it, we will be late, if we are below it, we will finish earlier
5. the actual Burndown line, it goes down by as much as the team completed on that day according to the definition of done
6. if we see a horizontal (0 slope) line, we should always investigate, by questioning, if it is caused by: 
   1. preparation?
   2. initial difficulties?
   3. too many parallel tasks?
   4. something that has happened with the team?
   5. someone has messed with the resources?
7. similar to point 6, but here the previous strong break could also be reasoned by suddenly needing do a lot of things, e.g. 
   1. to integrate
   2. to test
   3. to fix bugs
   4. to stabilize
8. the name of the team
9. the Sprint that the team is currently running
10. the date of the team demo. all demos are public!
11. the date when the team will finish coding and start preparing for the demo
12. the goal of the specific sprint. The business logic unit to be achieved in the Sprint
13. the person who is the central actor in the Sprint goal

For example, we can see how many times there are horizontal sections in the Burndown Chart. These are days when tasks were not actually completed. Development activity was going on, but no items were added to Done.

The Burndown Chart can go down only if an item has been put into the “Done” state according to the definition of done!

Once we already have a few days of measurements, we can project how many days before or after the planned date we will reach the finish line.

If this date is later than the originally specified end of the Sprint, it is forbidden to extend the sprint! In such cases, the product owner shall determine which stories or backlog items can be dropped from the sprint until time is gained somewhere. So we always have to get the team back to the ideal curve, even if it means taking away tasks.

Taking a task out of the sprint does not mean that the task has been completely eliminated from completion! It just means that the task does not fit into that particular sprint. If priorities have not changed, we can safely start the next sprint with the skipped task. But this must be a conscious decision every time, and not an automatic one!

If the extrapolation line shows that the team finishes earlier, it will also show by how much. Then a joint decision can be made with the product owner on how to use the time gained. It can be spent on: learning, teaching, planning, reducing technological debt, research. Additional development tasks should only be included at the expense of the time gained if absolutely necessary.

We can also read the number of horizontal lines. If the team draws a horizontal line for two consecutive days, the product owner should immediately intervene and ask questions about why we haven’t been able to finish anything in two days.

The Burndown Chart, if it shows an unfavorable picture, should never, under any circumstances, be used by the management to punish the team! The only healthy step is to ask inquiring questions based on the chart that the team or scrum master can answer.

The management should always welcome bad news with sympathy and gratitude! This ensures that the team trusts the management enough to always admit mistakes early on, giving the management the most important thing: the opportunity to intervene in a targeted and timely manner.

I also want to be a Scrum Master!