When is the story too big?

May 14, 2009 by Peter Stevens

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.

When should you advise your team not to accept a story because it is too big?

3 Warning Signs

Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:

1. Past performance indicates you won’t get it done
2. The story is large compared to the team capacity for the sprint
3. The demo is complicated and / or demos many sub components.

Past Performance is a good guide to future performance

One basis is past performance (often called “yesterday’s weather”). If your velocity (capacity per sprint) is 25 Story Points and yet your team was unable to complete a 13 point story last sprint, then the team will probably have difficulties completing a 13 pointer in this sprint. (The same is true for total capacity: if your team completed 25 points last sprint, the 25 is a reasonable guess for the capacity in this sprint). Accept the inaccuracies in you estimates, and adjust your commitments accordingly.

Stories should be small compared to the size of the sprint

Another basis is comparing the size of a story to the total size of the sprint. 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.

‘How to demo’ makes the complexity clear

Finally, be sure to ask the product owner how to demo the story. This should be a simple, repeatable work flow which shows that the function does what it is supposed to do. If there are many work flows, then the story is probably complicated and getting all of the work flows to work may be a challenge. Furthermore, a story which defines a work flow or two and then says 'and other flows like story XY' or which contains the phrase 'et cetera' is suspect. I would insist on defining all the work flows needed for each for demoing each story.

And if the stories look too complicated, then splitting the story on the basis of the demo work flows might be a good place to start.

Splitting Stories which are too big

Personally, I find recognizing stories which are too big and splitting them in to right-sized stories to be one of the most challenging disciplines of Scrum. For the developers and Product Owner alike, it is a big change, since the splitting the story often does not produce a logically consistent feature set at the end of the sprint. It takes a sprint or two or three to get to a deliverable state.

So how do you deal with the challenge? How do you recognize when the story is too big? And how to you prevent stories from ballooning into huge, never ending monster stories?

Permalink