Questions About Burndown Chart

One of my colleagues had some questions about the usages of burndown chart while using Scrum.

Questions:

A. What burn-down means?

B. Why we need it?

C. It's something for boss, why I need to care about it?

D. Even if we found something strange, they are all explainable. It means nothing to developer. Why people treat it as a important tool in Scrum?

At the same time, my friend also had question about Scrum:

E. Scrum is not really good at status tracking and task dependency management.

I fully understand these questions, and I think he got the key idea of burn-down chart -- it's used for management, and it's really easy to be understand by the management. Management can get the trend of development from this simple chart.

And as a scrum master, I think the burndown chart means more.

Basic usage

A burn-down chart can tell us (some of them are extended from the changes of chart)

• Sprint progress
• trend of development

Well, these are easy to be understand.

Advanced usage

Further more, it is really a great tool which summarized the whole sprint. It's a graphic log of sprint. From the rising or falling of the line, you will be able to tell what happened in your sprint.

• if your burndown chart is smoothly linearly going down
• and if join point is the near your estimation, that means your project is in good state
• if join point largely ahead your estimation, then maybe your developers have really good performance, or maybe your scope cut
• if the join point is after your estimation, that means you have problem now, check your estimation with developer for further reason
  
• if your burndown chart shows an suddenly up, that means your scope changed, new task added
• if a suddenly down, that means
• if the line is flat, well, maybe your developer forgot to update their status, or it means task delayed

All of these mean one word: STATUS. Any unexpected up or down will tell us the issue or exception happened, you must update your plan.

Now we have a great tool for sprint retrospective, we can sit together and let each of the members tell us what happened during the sprint. And we can easily summarize the lessons or issues or risks or wrong estimations or technical issues, wow, everything. And Scrum master can use to adjust the plan, better manage the release and sprint. And the developer can adjust their estimation, think about how they solve the issues they met.

And an important usage of burndown chart, actually I already mentioned above, using for comparison and adjusting the plan. The most difficult part of an agile team is the velocity. Normally, we can get the estimation from each developer, but the velocity of agile team will not come from estimation. The velocity comes from the real work done before. And the burndown chart is the right place we can got this information, well, you can get it from the task list too, but burndown chart is more straightforward, as I said, it also includes the exceptions of sprint execution.

Now we still lack of tool to better using the Scrum, I'm thinking about a tool which we can dynamically add issue/exception/risks/holiday or vacation to to system and they can be shown on the burndown chart. Then everything I said here will be easier for scrum teams. I'm waiting for this kind of tool.

At the end, I'm using a tool call IceScrum, you can try it if you want. Check http://icescrum.org for more details. It's a spring+jsf+hibernate implementation, a good application for studying.