Making small stories is something that Agile teams often struggle with. There seems to be a natural tendency to write large overarching stories. My teams have a hard time deciding how to break the story into several smaller stories that are easier to code, test and accept in a short amount of time.
Mark Levison recently wrote a post on AgilePainRelief.com on story slicing:
"Story Slicing, How Small is Enough?
When Agile/Scrum Trainers teach about new teams about User Stories, we usually talk about Bill Wake’s INVEST criteria which includes Small:
Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.
This statement is a great start but it doesn’t explain why or give you much guidance about what to do.
Why Small Stories?
Why not just give the team large stories that span iterations. Why are always asking if you can slice those stories smaller? A number of reasons:
- Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story.
- When you still have development to test handoffs (i.e. before you start doing ATDD (Acceptance Test Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code.
- Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt.
- Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something! ..."
Read the rest of Mark's post at AgilePainRelief.com.