When is a story too large?

Peter Steven's posted on the Agile Software Development blog today on the topic of "When is the story too big?" It's a really good article if you are on a team having trouble with that single story that deep-sixes the entire iteration.

Some of his points are:

• Past Performance is a good guide to future performance
• Stories should be small compared to the size of the sprint
• ‘How to demo’ makes the complexity clear
• Splitting Stories which are too big

On the second point he states:

My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

I actually took this a step further in my comments:

I would decrease your 40% further.... I am a strong believer in MMF (minimal marketable feature) and encourage items that can be broken down smaller to be. If something can be built and marked DONE in a day, that is better. Remember, sizing allows for change in scope and priority mid-iteration if needed. Large stories block this.

Thus, my rule is around the 25% mark. If a story will consume more than a 1/4 of the resources in a sprint AND it can't be broken down further, then I call for a spike. Use the spike to R&D the riskiest parts of the story and flush out the demo/acceptance criteria. Timeboxing the spike to 10% of the sprint forces re-evaluation before creating a huge time sink (allowing time to refocus 2nd spike in the same iteration if necessary).

The outcome of this timeboxed "spike" should be a more clearly defined, lower risk, and possibly broken down set of stories. Containing the work to a timeboxed spike insures the team continues to deliver other stories in the meantime.

Also... these stories should be tackled early on in the release cycle. If you wait until the 2nd to last sprint in the release cycle, your risk will probably cause you to miss it.

A lot of people forget about risk management in agile, I believe that proper story sizing is part of the risk management that teams must be accountable for when becoming a self-empowered, self-managed agile team.

Your thoughts?