Burndown Charts-Some Myths and Tips
In one of my recent assignments as a Scrum Master, management asked me to prepare a report every week. One of the key elements of the report was ‘Sprint Burndown Charts’.
I asked the management, ‘why do you want me to put burndown charts in the report?’ The answer was ‘So that we can track the team’s progress’. Straight away, my scrum master smells senses kicked off and I realised, I have got a big job to do. What should a scrum master do in such a situation?
Though a Scrum Master should not create a report in the first place itself as this purpose is fulfilled by Sprint Review. But this article is more focused on the use of Burndown Charts. Before coming to my views on this, let’s first discuss what Burndown Charts are.
Note: I will mainly focus on the Sprint Burndown Charts. Some Scrum Teams also use Burndown Charts for the release scheduling/management as well.
Sprint Burndown Charts are tools that help in building the Scrum Team’s self-organisation.
They are very powerful, simple tools and display the status of progress visually. It helps the Development Team to inspect its progress and re-evaluate the plan. A team can use the data shown in the charts to supplement the conversations and make decisions to meet the sprint goal/.
Because of their misinterpretation, these charts can be abused and lose their intended value. In some cases, burndowns don’t reflect the true picture. Even, I have seen some teams completely dropping them as they don’t see any value.
Teams that rebel against sprint burdown usually are rebelling against the use of the burndown by other parties such as stakeholders/management. By Geoff Watts, Scrum Mastery.
Usually, There can be two types of such charts:
- Sprint Burndown- Remaining Time Estimates
During Sprint Planning, generally, teams decompose the selected Product Backlog Items(PBIs) into smaller tasks such as Building database, Automate build, etc and estimate these tasks into hours/days. The sum of these estimated hours against each task at any given point during the Sprint gives a figure ‘Remaining time estimates’.
Note: This kind of burndown shows the reflection of teams' new learnings identified during the Sprint. For example, if there is a big upward spike, that means the team has learned that their initial understanding of complexity and effort was wrong.
Caution: A healthy-looking Remaining Time Estimate Burndown doesn’t guarantee that everything is happening as planned. (See the example described later in this article.)
2. Sprint Burndown- Remaining Story Point Estimates
This Burndown chart shows the story points related to ‘Not Done’ Product Backlog Items(PBIs). It is a reflection of ‘Done’ work.
For example, Team A selected PBIs A, B, C, D during Sprint Planning. Till, Day 5, only PBI A is ‘Done’, rest all PBIs are still In Progress.
Sprint Backlog looks something like this (this is purely for illustration purpose), Column ‘Actual Estimate(Hr)’ represents estimated hours for each identified tasks. Teams can also identify new tasks during the Sprint as well.
Then Burndowns will look something like below:
How to Use Data in Burndowns: Consider the example above
During Day 6 Daily Scrum, Sprint Burndown was presented like above. Only 3 story points burned but the remaining time estimate burndown is looking healthy. What would you deduce from the burndown charts like this?
This shows that individual tasks completion is going great but ‘collaboration’ is missing. Some observations can be that Product Backlog Items are not getting ‘Done’ as testing has not been completed. These observations can start new conversations around ‘how to get some more PBIs Done before Sprint Review’, ‘why there is more work in progress items’, ‘can someone help in getting testing completed’.
Story point burndown and Remaining time estimate burndown, when used together provide much better insight.
As a Scrum Master, I could observe that it is not a ‘One Team’. Probably, they are co-operating but not collaborating. It would have been difficult to know if both Sprint Burndown Charts were not visible.
Tip: Make these charts highly visble.
In the above story, it was only possible for me to sense the lack of collaboration by looking at Sprint Burndown Charts. Makes these charts highly visible so that it can act as an information radiator and help the team to make the required actions to meet the Sprint Goal.
Tip: Make burndowns key element of the Daily Scrum.
Daily Scrum is a key inspection and adaptation event and burndowns provide very good information for the Development team to collaborate and replan if necessary.
Myth: Burndown Charts are for management to track the progress on a daily basis.
Continuation from starting of the article where management was using Burndown charts for tracking for the team’s progress on a daily basis. Burndowns are not a management report. Burndown charts can be easily misused as a micro-management tool.
My opinion: A scrum master stance should be to coach management around the true purpose of the burndowns. He/she should also make them aware that there can be long term implications such as lost transparency. Management should understand that this act can be considered as micro-management and that generally implies a lack of trust in the team. He/she should also try to understand the true purpose behind management’s desire. It may happen that they want some data for their decision making and consider burndowns as a solution for it.
Micro-management occurs mainly because of lack of trust.
Myth: Maintaining Sprint Burndown Charts is the Scrum Master’s responsibility.
I have seen many development teams believes that maintaining the Sprint Backlog is Scrum Master’s responsibility. Such teams must be coached that these tools are for them so that they can self-organise. Development owns estimates. These estimates are reflected in the burndown and no-one is better than the development team itself to maintain these charts.
Only the Development Team is responsible for estimates. — The Scrum Guide.
EndNote:
It is quite easy to blame the tools/processes/practices for some failures. But most of the time, it is the adoption that is faulty. Burndown charts are a very good example of this. A powerful and simple tool that can be easily abused for un-intended purposes. If used correctly, these charts can help to build the team’s self-organisation.
Please provide your feedback and also let me know if you have come across a scenario where burndown charts used as a powerful tool or as an abused tool.
