How to Use Burn Down Charts During a Sprint
The Best Practises of Using Burn Down Charts in Scrum
What are the best practises of using burn down charts during a sprint? - These are the things you should be paying attention to when using burn down charts to track your sprint progress in Scrum.
Who should update the chart?
There is a bit of debate even in the Scrum community around who should update the burn down chart.
As long as the chart is used as a tool by all of the team it shouldn’t matter too much who physically updates the chart. If it’s convenient for the team, the Scrum master can update the chart once per day before the daily Scrum so that the team can inspect the latest version during the event.
On the other hand, if the development team and the product owner choose to update the chart themselves whenever a story moves to done it can give them a sense of achievement. This increases ownership by the team and can potentially make the use of the chart even more impactful.
Realistically when a team starts using burn down charts, the person who introduced or suggested the tool - often the Scrum master - will have to maintain it for a while until the team is fully on board.
Some will also argue that it is best if the development team updates the chart since they own the sprint backlog and the burn down chart tracks progress on the sprint backlog.
Make it visible
Scrum is all about transparency - A great way for a Scrum team to make its work more transparent is to put its burn down charts up on the wall next to the sprint board. This will not only help everyone on your team know the exact progress of the sprint. Also passers-by such as members of other Scrum teams or management can see exactly where you are at.
This sends a message of transparency to the other teams and to management and it might have people stop by the chart and start asking questions. This can then spark deeper conversations about the team’s work which is where the real value lies. If the burn down chart is a conversation starter it will lead to more knowledge exchange about both technology and ways of working.
What to do if the burn down chart doesn’t look healthy?
There are a couple of undesirable burn down chart patterns outlined in the article about what makes a good burn down chart. The burn down chart is a great tool to look at during each daily Scrum and assess what is not going well and to identify potential blockers.
If the chart doesn’t look as you would like it to, try finding out what the bottleneck is. Some problems can be fixed right away e.g. by unblocking a team member. Other problems have deeper underlying causes that can be addressed during the team’s retrospectives. The past sprint’s burn down chart is a great tool to look at during your next retrospective.
Some problems surfaced by the burn down chart can go as deep as to the organisation itself. If your team regularly meets only half its commitment because the second half of the sprint items is still with the outsourced QA teams this is an issue with the agile adoption in your organisation. It should be addressed together with management and the Scrum masters of the other teams.
Please keep in mind your original decision to be transparent with the team’s work. It might be tempting to start hiding your burn down charts from the rest of the company once they do not look healthy. Hopefully there is enough trust in your organisation to be able to be honest about when things are not going so well. Some teams start creating fake burn down charts that show progress how they think management wants to see it while they are struggling internally. Only to find out that things are falling apart months later when problems cannot be hidden anymore. The burn down chart should be first and foremost a tool for the Scrum team itself to inspect and adapt. Using the chart as a tool for reporting and to please management is a misuse and should be avoided.
Don’t micro manage
There is a certain danger that when inspecting the progress of your chart every day for Scrum masters to start chasing up the development team too closely whenever the chart diverges from the ideal. The development team collectively owns the sprint backlog and the burn down chart should be a tool owned by the team to inspect and adapt their work.
The sprint burn down should not become a tool the Scrum master uses to chase up the development team whenever the actual work is diverging slightly from the ideal. This will only make the development team disgruntled and not wanting to use burn down charts anymore.
The Scrum master should instead highlight to the team the value that a burn down chart can bring in discovering problems during the sprint. The Scrum master can then help resolve impediments. At the same time she should always trust the team to adapt and to get the work done.