Tag Archives: planning

Burndown Charts That Suck #1

Over the past year or so, I’ve collected some burndown charts that illustrate some team problems. I don’t want to tell tales on past clients, so no names will be revealed by me. And for that matter, people always mean to do their best, but sometimes it’s an emotional challenge to fix things (see the second to last paragraph below).

For each image, I’ll list a few ideas I have about why the team’s progress looks as bad as it does.


  • mis-use of an agile tool (stories weren’t “in” the sprint when the start button was pushed)
  • stories not broken down into small enough pieces
  • probably not really using daily meetings to report progress.

  • mis-estimated some of the work, or actually had done work before the sprint started
  • …and then somehow managed to get stuck on the remaining work
  • meanwhile, a points worth of work failed at the end of the extended sprint–why wasn’t some qa-like work done earlier?

Screen Shot 2014-11-18 at 9.38.34 AM

  • Oh please. Admit that you didn’t meet the commitment, and move unfinished stories into a new sprint. Figure out why you struggled, and fix that problem.

I think there are two themes that pop out here. The first is using and relying on a tool before fully understanding the underlying principles. That first image, where all the scope of the sprint is added after the sprint has begun, illustrates a simple “record-keeping level” problem. But there are larger problems with tools. They’re built for some specific requirements, requested over time by people using the tool. But those people are not you or your team. You and your team will look at all the fields and dropdowns and buttons on the tool’s interface and decide you have to use them, even if you don’t know what they are for. Before figuring out what is important for you to track, you are puzzling over how to use someone else’s idea of tracking. This just leads to confusion and losing your focus to things that are actually meaningless to you.

When coaching, I really do prefer to start teams using paper and pens. Using simple manual tools forces simplicity. Simplicity gives you the chance to understand the process you are creating before it grows.

The second is a more emotional issue: teams are uncomfortable to admit failure.  Look at that last image. It is the map of a massive failure of some sort. “Extending” the sprint is much less confrontational than saying “something is broken.” But as hard as it is to admit failure, admitting failure is the first step in fixing the causes of that failure.

I don’t know if I heard this phrase somewhere else, but I’ll use it now: “Fess up when you mess up.” Then use your retrospective to make some improvement, somewhere in your process, or your team organization or your client/product owner relationship. Don’t let your burndown charts look like these.

Punished by Ambition

One of the precepts that we–okay, I, for certain–take for granted in scrum is that teams should consider carefully how much work they can commit to in their sprints, use estimated size (i.e. in story points*) and past history as a guide, and only take on more work if they truly finish the work they’ve committed to. Intuitively, this makes sense. You want your teams to focus and finish work, not to start, or stub out, more than they can finish. Starting more than you can finish leads to making some progress with a lot of things, but being finished with few.

As I said, this makes sense intuitively. Recently, I came across a very nice empirical observation of the danger of over-commiting. I have to give props to one of my current clients** for providing this example, as well as providing the title of this blog post (although the phrase may have first been used by Sir Francis Bacon).

The team’s velocity, now established after more than 8 working timeboxes, is 60+ points per three-week sprint. This is shown on the graph as the 5-week moving average of points completed per sprint. But the team didn’t always know–or trust–that as a fact.

During their fourth sprint, even though they had never completed more than 81 points in a sprint, the team was pushed to accept 134 points as their committed work. They failed in a spectacular manner, completing less than a third that many. In fact, the number of points completed during that sprint was their second-lowest on record. (Their lowest-measuring sprint occurred early on when the team had almost no experience with agile techniques.)

So you can imagine what happened, right? The Product Owner, excited at seeing an upward trend over the previous couple of sprints, and perhaps agitated to release something soon, may have pushed the team to take on more work. Or the team itself, wanting to prove something, may have applied internal pressure. Whatever the exact reason, they took on more than they could handle. And the result was calamitous. Not only did the team not complete all the points they committed to, they in fact completed fewer points than they usually could.

In sprints 3.3 and 3.4, the team was more conservative, committing to 62 and 70 points respectively. And in both of those sprints, they were able to pull in work and complete more points than they committed to. (This pattern may suggest, of course, that their actual capacity is higher than 60.) But look out! Buoyed by those two successes, the team committed to 115 points in sprint 3.5, and again failed to meet their commitment. (To be fair, they did complete more than their average, so something is going right.)

The important point is that remaining focused, which in behavior translates to committing to fewer points/stories, allows the team to work more effectively and accomplish more than planned. And being aggressive in committing to work dilutes attention and results in worse than average performance.

* But for a good common sense opinion on NOT using story points for selecting work for sprints, see Mike Cohn “Why I Don’t Use Story Points for Sprint Planning.” I don’t think what he says negates the underlying message I’m trying to convey in my post.

** Not wishing to run afoul of any confidentiality agreements that may exist, I’m not going to identify the client by name in this blog posting.