

Class Registration
I came across this question\comment on the LinkedIn ScrumMasters group the other day asking about Burndown Charts and management analysis.
“I send out Burndown Charts daily and have been questioned by upper managent as to why we see fluctuations, up or down to the ideal trend line.”
For those that are unfamiliar, a Burndown Chart is a visual control used in Scrum to help the Team members to see if they are on-track (or off-track) to deliver on the Sprint Goal before the end of the Sprint. The x-axis has increments of time while the y-axis has some increment of estimated work remaining. It is a tool for the Team to help them self-organize, provide visibility on the true status of their progress and helps the Team inspect-and-adapt. The ScrumMaster has the responsibility to create the Burndown Chart at the beginning of the Sprint, but the Team members have the responsibility to update and maintain it throughout the Sprint.
The example below is a very typical Sprint Burndown Chart. Sprint Burndown Charts normally list the days of the Sprint along the x-axis. In this example, we estimated task points remaining on the y-axis, but you can use time or some other unit of measure. All the raw data for a Sprint Burndown Chart comes from the task estimates in the Sprint Backlog. In addition, I normally add two lines to a Sprint Burndown – a solid blue line that records the actual work remaining each day and a dashed green line which shows an ideal burndown. The dashed green line represents what a Team’s progress might be if they completed the same amount of estimated work each day.
Please keep in mind these two things about the ideal line in a Sprint Burndown.
IME sending Burndown Charts to management daily is just a bad idea and diminishes Scrum. Every time I have seen this in organizations it ends up weakening trust and making Team members feel really, really exposed. If you are doing this now, I encourage you to stop sending Sprint Burndown Charts to your management and Stakeholders. If you have Sprint Burndown Charts published in some electronic format all over your building or on wikis, it causes the same outcomes so stop doing that, too.
Here are my main reasons not to publish a Sprint Burndown Chart widely across an organization.
I understand why people want to distribute Sprint Burndown Charts and why managers and Stakeholders think they want to see this type of data. The data is easy to collect and readily available from a Scrum Team. Most electronic tools produce them seamlessly.
However, if managers and Stakeholders are involved with this level of detail of a Scrum Team, then I would suggest they are not doing their real job. IMO, their real job in Scrum is not to know what everyone is doing or boss people around. Their real job is to offer leadership, provide guidance, set direction and communicate with parties outside of Scrum. Unfortunately, discussing Sprint Burndown Charts and all their fluctuations only provides the illusion of control and that someone is “managing” the project or program.
So, if you want to show people something valuable, then show them a Release Burndown Chart. This is useful tool for managers and Stakeholders to discuss since it is focused on the value delivered and what remains. It is organized much the same way as a Sprint Burndown Chart, except in this case the raw data comes from the estimates for each of the Product Backlog items. For more information, please see my 2010 entry on how to read a Release Burndown Chart and be sure to check out the great comment from George Dinwiddie on Burnup Charts.