Why Your Burndown Chart is Always Off-Track

A lot of new engineering managers and project managers wonder why their agile burndown charts always look something like this:

Instead of following the neat linear “guideline” provided by agile project management tools, each sprint has a slow start, a bit of perhaps-worrying progress in the middle, and a huge drop toward zero the last day or two.

Why doesn’t our burndown chart burn down in a nice linear fashion? Are our engineers terrible procrastinators? Do they get desperate and redefine “done” at the last minute?

On the contrary: What your agile project management tool is suggesting doesn’t reflect the way that engineers actually work. There are a couple of reasons for this.

First, in order to have a neat linear burndown, you’d have to break user stories down into much smaller increments of points or weight or whatever you’re measuring. Project owners don’t operate by planning ten 10-point stories per sprint per engineer. Indeed, in most cases that level of detail would feel like micromanaging. And you’d likely end up with individual stories that provide little or no real user value, contrary to the intent of agile. So it’s much more common to have, say, five two-point stories, or three 3-point stories and a single-pointer, or some combination like that. Simple mathematics says that you wouldn’t see much in the way of progress until day two or three in the best case.

The more interesting explanation is that a linear burndown simple doesn’t reflect the way that engineers actually work. Engineers don’t work tasks in a sequential, blocking fashion, completing one before moving on to the next. That approach isn’t even feasible because of the number of subtasks that need time to coordinate, like requirements and design follow-ups, code reviews, approvals, and deployment and testing through various stage of infrastructure.

In reality, engineers are always working several tasks in parallel with each at various points in the process. You should be able to see that if you take a look at a well-designed and maintained sprint board, If those tasks all happen to make it to the “Done” rail on the last couple of days of a sprint, that’s not suprising at all, but rather just your engineers efficiently managing their time.

There are far better ways to track mid-sprint progress and productivity than a burndown chart. Let me know if you’d like to hear more about that!