In a Scrum team, burndown charts are a tool you can use to track progress throughout the sprint and use as a benchmark, over time, to forecast potential productivity on future sprints.
It can be facilitated on something as simple as a whiteboard or it can be used digitally across a range of platforms that have been created to facilitate digital burndown charts.
It starts by tracking the number of points completed from the sprint backlog items on the X axis of the chart whilst tracking the number of hours or days on the Y axis of the chart.
As each backlog item is completed, a member of the scrum team will mark that progress on the X and Y axis of the sprint chart with a label for the work or activity completed.
In a perfect world, the ‘flight path’ of the sprint burndown chart would move from the upper left corner down to the bottom right corner in a straight line.
Sprint performance is a great deal more complex than that so you may find that whilst some items are completed ahead of schedule whilst others drift over the line in terms of anticipated completion.
It’s a great visual way to track sprint progress and allows everyone on the team to see whether they are on track with the sprint tasks and goal or whether they need to step things up a touch.
They aren’t essential in terms of scrum but have proven to be both popular and useful in the past.
The question as to who should facilitate the burndown chart is a matter of discussion for the scrum team.
Some people suggest that the Scrum Master should be responsible for the scrum burndown chart but it simply doesn’t make sense to do so as technically, the scrum master is the least interested in what the burndown chart represents out of the entire scrum team.
Some people would recommend that the product owner is responsible for the burndown chart because they have the highest vested interest in what has been completed and what is still considered a work in progress.
As they are responsible for communicating with customers and product stakeholders, they have a very high interest in how the sprint is progressing and what items can be anticipated at what time during the sprint.
Others advocate that the developers themselves manage the burndown chart.
They advocate this because the development team are responsible for the work and will benefit from tracking what is progressing to schedule and what may require swarming or additional assistance to ensure it is delivered within the sprint.
My personal recommendation is that the developers maintain the burndown chart and if necessary, communicate any impediments to the scrum master and product owner as soon as it is clear there will be a problem in delivering the backlog item during the sprint.
The sprint burndown chart can also be a useful tool for discussion in sprint reviews and retrospectives. It provides the scrum team with a visual representation of how effective the sprint was and how well the team were able to deal with the amount of work that had been allocated.
The chart can inform future sprint planning and help the team identify what the optimal amount of work in any given sprint should be. It also informs the sprint review and retrospective by demonstrating what problems were encountered and how things could be improved moving forward.
I do believe that the burndown chart can be valuable for scrum masters to understand how a team is performing as a unit and where potential bottlenecks have created problems for the team.
It can serve to inform points of discussion in the sprint reviews and retrospectives which helps the team focus on what is necessary for improvement in the future.
So, in summary, burndown charts aren’t necessary for scrum teams but they can be useful. I would personally recommend that the development team are responsible for the burndown chart and that scrum masters and product owners could derive value from having discussions around anomalies in the sprint by referencing the burndown chart.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.
If you are a scrum master with over a year’s experience, visit our Advanced Certified Scrum Master course page.
If you have several years’ experience as Scrum Master and would like to validate those skills, visit our Certified Scrum Professional Scrum Master course page.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy course page.
For more information on John McFadyen, visit https://www.johnmcfadyen.com