By Pat Guariglia
The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.
The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.
