Is the Way You Use Burndown Charts Helping or Holding You Back?
Origin and Purpose

The burndown chart originated with Ken Schwaber at the turn of the millennium. His intention was to provide scrum teams with a simple toolkit to use during a sprint. In the years following its invention, it gained popularity and saw widespread use. At its core, a burndown chart is a simple graph. It has the amount of work remaining on the vertical y-axis and elapsed time on the horizontal x-axis. A straight line is then drawn between the upper left and lower right corners. This line represents the ideal progress during a sprint.

The chart is intended for a single task: monitoring the progress the team is making towards achieving the sprint or some other defined goal. The original concept made use of total estimated hours for the vertical axis and days for the horizontal axis.

Can we meet the goal is the only question a burndown chart answers.

Anyone who has worked in development knows that accurate estimation is near impossible. Once you start to work on a task, you are entering into a learning phase. This nearly always leads to discoveries that were not included in your estimate. So the estimate to complete needs to increase. The inability of teams to accurately estimate effort for IT has been known since the early days of computing. It was even an agenda item at the first-ever NATO IT conference in 1968.

Consider this example. You estimate eight hours to complete. After working for four hours, you believe that there are still eight hours of work remaining. This is the reality of development in an IT setting. The burndown chart tracks the new total estimate to complete at the end of each day against remaining time. The team will then use it to judge if they can still achieve the sprint goal given the estimated total of work remaining and the remaining time.

Using the burndown chart in this way requires the team to re-estimate the remaining total work on a regular basis. If they do not, the burndown chart becomes worthless. In the 20 years that burndown charts have been around, they have evolved to better reflect the way we currently work. They have also been hijacked by traditional managers and used to monitor and control the team, turning them from a useful team tool into a weapon of oppression.
['Mark Gray']
['Technology', 'Leadership', 'Programming', 'Product Management', 'Agile']