Should You Draw The Sprint Burnbown Chart?
With this post I want to shed some light on my experiences with Sprint Burndown charts. Especially the question of who owns the Sprint Burndown chart and is responsible for drawing it. In case it is not presented on a flip chart, the matter will be about who maintains the status in the used tools. Should it be done by the team that implements the software or should it be done by the person responsible for planning the scope, the product owner. In Scrum, a method of agile software development, should it be possible that the scrum master or agile coach draws the Sprint Burndown chart?
Before we narrow down the topic, let’s look at what a Sprint Burndown chart is good for. A Sprint Burndown chart is a chart type which shows work left to do and the remaining time. Burndown charts are widely spread in agile software development. In this post we will look at Sprint Burndown charts in the context of Scrum. However, Burndown charts are not limited to agile software development and could be used wherever completion of work packages is measured over time. The picture below shows a classical Sprint Burndown chart as it is used in Scrum.
There are several people who are interested in work progress, such as product owners, team members, sponsors or clients. Also scrum masters or agile coaches have stakes in Burndown charts.
Let’s look closer at the different roles in Scrum and what interests they have in Burndown charts. In Scrum you will find the scrum master, a role with the responsibility of helping teams to become agile and preserving the teams agility. For definition and prioritization of scope you have the product owner role and for implementation the team consisting of individuals.
Having the scrum master drawing the Burndown chart is not an option. The role of a scrum master is to enable and support the team and the product owner in working in an agile way. The scrum master is there to ensure that everyone knows how to do their work according to the agile manifesto, the agile principles and the Scrum guide. Therefore the scrum master is only interested in Burndown charts from a methodology point of view, not from a progress of work point of view. Surprisingly often though, I’ve seen projects where the scrum master actually drew Sprint Burndown charts. If that is the case in your project, this needs to be addressed.
The next role that comes in question for drawing the Sprint Burndown chart is the product owner. That’s possible but not a good idea. The product owner is actually the receiver of the information reported by a Sprint Burndown chart. Product owners are interested in the progress of work and when work will be finished. They are responsible for what should be implemented, that the product is valuable and meets quality criteria. Whereas the team has to take care of how to implement the product. The product owner would have to ask the team about details of implementation in order to understand true progress of work. To keep it short, product owners are the wrong persons to draw a Sprint Burndown chart. Product owners draw Release Burndown charts, which shows the progress across several sprints.
Scrum masters and product owners are not the ideal roles to draw the Sprint Burndown chart. The team is in a much better position to do this because it knows best the progress of work that is being done. At least it should, otherwise the scrum master might have a subject to talk about with the team. The team is implementing the scope that was defined by the product owner. With that the team knows exactly if implementation is going the way it was planned or if obstacles came up which cause delays. To make this visible is the purpose of the Sprint Burndown chart.
All roles work together regarding the Sprint Burndown chart. You have a team that owns the Sprint Burndown chart and is responsible of making the progress of work transparent to stakeholders. Product owners use the Sprint Burndown chart to determine whether the project is on schedule or if the release plan needs to be updated. In case the team or the product owner struggles with their role and their responsibilities, the scrum master is there to support, coach or remind people of the rules that are underlying agile software development.
To close this post, I’ll mention another benefit that comes when teams are conscious that they own the Sprint Burndown chart and draw it. This is often the first step towards self-organization, which is the desired state of teams in a Scrum context.
Sources & Links:
Leave a Reply