Tag Archives: teams

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.