IT Bytes

I’ll be honest, I much prefer burn-up to burn-down charts. However, for some reason the tooling to support these is horribly lacking so I often find myself being presented with a well meaning burndown chart.

A burndown chart is there to show an estimate of how likely a team will deliver a block of work in an amount of time. A Sprint is there to provide a focused deliver of a block of work. The two often go together, and this is where I start to have an issue with them. When software delivery described an early delivery as 6 months it was very important to attempt to track if the development was on schedule. In order for a burndown chart to help with this the team needs to spend a certain amount of time recording what they’ve done and re-estimating what they have left to do. When Sprints first became popular a 4-6 week time-box was not unusual. This still represented an expensive period to fail in, so tracking was still important. Today a 2 week Sprint is very popular, if you fail then it’s not nice but lessons will have been learnt and you have only ‘lost’ 2 weeks. So is it necessary to track the progress of such a short time period? If you get to the end of the first week and your burndown trend isn’t on track, what are you going to do about it? To maintain the burndown chart the team have to expend time to keep the estimates updated. This doesn’t represent a trivial amount of time from a 2 week period. So…what is the point of a burndown chart for a 2 week Sprint? In my view you will be better off simply recording the outcome of the Sprint in terms of delivered items and save the effort on re-estimating and daily report production.