Agile antipattern: Another burndown chart that lies!

That burndown chart looks sweet doesn’t it?  The team finished the iteration on time.  What could possibly be wrong.  Well, a lot actually.  Notice that one day this team completed a tremendous amount of work.  Do you ever see teams really do that?  It certainly could be a symptom of allowing large stories and they just got completed that day.  But I’m not buying it.  When I see a chart like this I immediately think the team is hiding something.  Most of the time they are hiding that they changed the scope for the iteration.  They saw their trajectory and simply said we have to remove some scope in order to have a successful iteration.  DO NOT BE TEMPTED TO DO THIS!!!  There are far better ways to fail.  If a team starts to believe this is ok then they will use it as a fallback position too often.  How do I know this is the situation?  Easy, I look at the burnUP chart.

A burnup chart measures not only completed story points for an iteration or release, it also has a line representing the commitment the team made.  In this case the chart is quite enlightening.

Now we can see a completely different picture of how the team performed during the iteration.  They removed scope from the iteration and faked a success.  They decided they didn’t want to move work from one iteration to the next (another antipattern I wrote about) and instead they failed in what I believe is an even worse way.  Nothing gets learned from failing in this way.  The team did not meet their commitment, but we really have no idea if they were even approaching it well.  Wouldn’t it be better to see what work was left at the end of the iteration and determine if the team at least worked in priority order?  Based on the work remaining we might even be able to come up with some ways to help the team.

Fail in the right way (leaving low priority items which have not been started is best) and learn how to do better next time.  Agile failure is ok if 3 conditions are met: fail fast, learn from it, and don’t do it again.  In this case the team failed fast but they don’t have a good way to learn from it and there is no incentive to do it again since it looks like a success on the burndown chart.

In case you can’t tell, I prefer for teams to use a burnup chart when possible.  It exposes more issues and keeps the team more accountable.

Until next time I’ll be Making Agile a Reality^® by helping teams understand it is important to be transparent with their metrics.