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.

1. Plotting the ideal line on Sprint Burndown Chart is not required in Scrum.  It is only interesting as a way for the Team to quickly see if they are on-track or off-track.  When the blue solid line is above the dashed green line, it represents the Team is off-track and when the blue line is below the green line, the Team is on-track to deliver everything before the end of the Sprint.
2. The ideal burndown is a COMPLETE and UTTER fiction since it is impossible for Team to match the ideal burndown rate day after day.  A Team should not be encouraged to match the ideal line or measure their effectiveness as a Team by how close they match the ideal line.  Again I will reiterate the first point, the ideal line is just an interesting conversation starter about is the Team going to meet their commitment (or not) and what actions needs to be taken to ensure the Team hits their target.  If you have a Team that matches the ideal line, they are falsifying their data.

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.

1. This is not a management tool for people outside the Team.  The day-to-day management of the tasks, managing their completion, eliminating delays and dealing with risk is the responsibility of the Team.  The Sprint Burndown Chart reinforces the Team’s accountability to deliver working product and encourages them to inspect-and-adapt when they notice they are behind.  In addition, the day-to-day fluctuations in a burndown are meaningless to anyone outside the Team.
2. When we share Sprint Burndown Charts to people outside the Team, it invites micromanagement and diminishes the Team’s self-organization and commitment.  If I showed the example above to people outside the Team, they would start asking a lot of  questions around March 16th – “Is the Team on track?”, “Why are they so far behind?”, “Who is reponsible for the delay?” and my absolute favorite, “What can we do to help?”  Managers and Stakeholders simply cannot help themselves since they see the chart with the all the fluctuations and just assume their is “a problem” and you are asking for their help.  These folks, operating from the best intentions, think they are helping with their questions but in reality are only distracting the Team and showing they really do not trust the Team can get the job done.
3. Sprint Burndown Charts provide a false sense of progress.  Progress in Scrum is not measured by completion of tasks according to some arbitrary ideal line, but through the delivery of valuable product at the end of each Sprint that is potentially shippable.  The only way that can be determined is if managers and other Stakeholders attend a Sprint Review of working software.  A Sprint Burndown Chart tells you nothing about value.

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.