Burndown Chart or Wishful Thinking?

Do you experience that the Burndown Charts look really positive throughout the Sprint, but in the end, the team still fails to deliver the Sprint commitment?

This article will help you avoid some of the psychological pitfalls when generating your Burn Down Chart.

The original version
When the Burndown Chart was initially designed, the idea was that it only showed progress when things were done. The philosophy was (and still is) “to focus on getting stuff done”. You can say many positive things about good intentions, but they only bring benefit once realized.


The pragmatic solution
One of the challenges with the Ideal version of the Burndown Chart was that a lot of Scrum Teams had difficulties in defining independent tasks and therefore delivering “Done” on a daily basis. The Burndown Chart would therefore always be behind schedule, even though the team was On Track.

You can of course argue that the teams just needed to get better at defining independent tasks, but in reality, we probably all tend to go for the pragmatic solution. To overcome the problem of overly negative Burndown Charts, the “In progress” curve was introduced.

Home to Mama
As a smart guy once told me (thank you Martin :-)), we all have a tendency to “run home to mama” when things get tough – meaning that we fall into old habits when it becomes too hard to do “the right thing”.

Throughout the history of waterfall, progress was monitored by having developers constantly maintain the number of Remaining Hours on a given task.

When looking to establish an “In progress” curve on the Burndown Chart, the traditional approach was simply incorporated into the Burndown Chart. Even when looking at standard tools like Microsoft TFS, the Burndown Chart is based on Remaining Estimates.

What amazes me the most, is that most people seem to actually believe in the Remaining Estimates – even though history tells us that remaining estimates are reduced by 80% when 20% of the work has been completed (who will estimate that they are making a mistake?).


The way forward
In order to get more correct Burndown Charts, while improving the work process in the team, you simply need to introduce a few simple changes:

  1. Don’t allow “Test tasks” – Make testing a natural part of every task
  2. Change the “In Progress” curve to be based on calculation instead of relying on Remaining Estimates.

I recommend using the following formula for calculating the “In Progress” curve:

[Burn Down] = ∑[Story Points] – (∑[Story Points (Done tasks)] + 0,5*∑[ Story Points (Tasks in progress)])

During the first Sprint after changing the “In Progress” curve, you might experience some frustration in the team, because the curve “acts wierd”.

There can be several reasons why this happens, but the good thing is that they all point the team towards new learnings and better performance.

Here are some typical things to look for when calculating the In Progress curve:

  • The curve seems to run at half pace This is usually caused by lack of continuous testing. Since tasks only count half until they have been tested, the “damage” of not testing will become very visible.
  • The curve moves in intervals This is usually because the defined tasks are too big, or that tasks are interdependent.
  • The curve moves fast in the beginning of the Sprint – and then almost stops This usually occurs if the team starts work to too many tasks, without getting the Done.

If you really focus on the above, there is a good chance that your team will mature to the point where the “In Progress” curve is no longer needed :-)

If you have found this article useful, then please don’t hesitate in sharing the word.