Burndown Bingo – An Agile Anti-Pattern

November 6, 2011

Your newly minted global agile team is dutifully performing the rituals typical of agile development.  They do their morning scrum, they update their remaining task hours, review their burndown chart, and so forth every day.  The end of the sprint comes, they deliver successfully, and during the retrospective the business praises them highly for how their actual burndown tracks closely with the ideal trend line on the burndown chart.  The team is happy.

The next sprint is going along well but mid-sprint the business looks at the burndown and notices the actuals are not tracking so closely anymore (not wildly off course, just noticeably more than the last sprint).  At the next standup the business raises mild alarm at the deviation and wants to know why, why?  Now the team is not so happy.  One of the distributed teams appears very concerned about the displeasure expressed by the customer.

As the next sprint is planned, the product backlog item estimates from the distributed team seem unusually uniform and unrealistically high.  The hours estimated for their sprint tasks are “healthy” also.  Amazingly, during the sprint the actuals now track EXACTLY with the ideal trend line.  Not close – exact.

Hmmmm.  Could just be random luck and serendipity.  Could be an error in the burndown calculations.  Or could it be that the worried, distributed team (who are the last chronologically to update their hours) has enough “padding” in their estimates that after the other teams update their hours, the worried team updates their remaining hours so precisely that – BINGO! – the actuals precisely match the projection,  every day.  Naaah!  Couldn’t be. …………. Could it?

Ever seen such an anomaly on your projects?


  1. Yep. I’ve seen this before. On the first point about the business being concerned by the slightly deviating burndown, one member of the dev team called it the “metaphorical stick” which management would beat the team with. It did actually get so bad that we dispensed with showing the burndown to managment for a while as it created too much confusion. Even after much discussion and meetings they couldn’t understand that this ideal line wasn’t a target to follow blindly and the burndown didn’t give the full, true picture of what was really going on in the sprint.

    On the second point I had a team which deliberatly padded out the estimates in order to make the burndown look “nice”, Nice for who? Them or management? Some of the team did eventually come round to the reality of what they were doing but I didn’t understand the concerns from the team about why there were doing it. For managment it’s black and white for the development team it is sometimes grey. Still, it didn’t help that we had a team member who regularly produced individual burndowns for the team and attempted to tell them where they were going wrong. He wasn’t even the Scrum Master so this presented it’s own problems.

    Anyway, burndown bingo is not new. Human nature rears it ugly head a times likes this. I don’t find it suprising at all that the distributed teams pads out their hours like this.

    William Boon

  2. Great post Bob!

    The burn-down can help teams stay on track, determine problems and opportunities, as well as manage the scope up or down based on how the team is progressing.

    When teams are overly praised for how well they track to the ideal burn or chastized for deviations they will quickly learn to modify their behavior.

    Ultimately it’s the Product Owner / Customer and ScrumMaster / Coach to not overly react positively or negatively to the burn. Rather, just help the team take the proper corrective action.

    I always believe the burn-down is just a data point. The information is neither good nor bad, it just is.

    • Yup, this is just an example of a problem you run into as soon as you start creating any kind of KPI, measure it, and reward/punish people based on those KPIs.

      The problem, of course, is that you will get exactly what you measure for (that this might not be what you actually *want* is beside the point…).

  3. Is the problem that the burndown chart is supposed to be a work-a-day tool for the team and not a measure for managers?

    I prefer the sprint burnup chart for the overall project evaluation by managers. You only see the output per sprint, which is the only thing that matters, right? Of course, managers do often want more. I’ve seen feature charts with value stories that are used for management. Also overall red light/green light charts that alert management to impediments – those seem useful.

    The biggest issue in Agile always seems to come back to managers needing to feel they are in control. In Agile, managers are supposed to be concerned with roadmaps, strategic vision and impediment removal – big things.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: