Jeff Patton is one seriously smart guy. I really need to pay much more attention to what he writes. While reading his older blog entries, I came across this nugget in an article attacking the myth of bad estimates sinking agile projects. Even entirely out of context, it’s great:

Treat estimates as solution budgets and focus on solving the original problem

Suppose the programmers estimate a story at 1 point, which happens to be around 3 days’ work on this project. Now suppose the team starts writing customer tests for this story and the story balloons into 2 weeks’ work. What should we do? Here are some options.

  1. Let it be 2 weeks’ work, then re-plan and re-prioritize.
  2. Work overtime in an attempt to squeeze 2 weeks’ work into 3 days.
  3. Yell at each other over it.

Sadly, I see the teams take the last option more often than the others. They might yell subtly at each other, but they yell all the same. If the programmers have the upper hand in the relationship, they insist it’s 2 weeks’ work and they force the customer to re-prioritize and re-plan. If the customers have the upper hand in the relationship, they insist it be done in 3 days, and the programmers “knuckle down” to try to do it. In each of these cases, the result is not good.

Now there is another option I didn’t give earlier. Split the story into smaller pieces, the most urgent of which we hope is only 1 point. This is usually more effective, but I have already written about how difficult this is to do well. I wish I had read Jeff’s words before I wrote what I did, because Jeff’s advice provides a concrete goal for splitting this exploding story beyond “it’s a good thing to do1”. Combining Jeff’s advice with mine, we arrive at something better.

Find the most urgent part of the story that costs only 1 point, then split the rest into less urgent parts that the customer can put back in the backlog.

This way, the customer gets the essence of what she wanted when she chose this story as the next one to build; but the programmers aren’t asked to do the impossible. It seems like a good outcome to me. Thanks, Jeff, for helping me justify my advice.

  1. I haven’t found much success justifying my advice to software people with “trust me; it’s good for you”. I’m constantly on the lookout for a better answer.↩︎