Story Slicing, How Small is Enough?

When Agile/Scrum Trainers teach 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. (For more on protecting the accuracy of those estimates from anchoring bias, see Blind Estimation for Planning Poker.)

Why Small Stories?

Why not just give the team large stories that span iterations? Why are we 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.
• The smaller the work item, the better we understand both the item and the rest of the product it fits into.
• When you still have development to test handoffs (i.e. before you start doing Behavior 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!
• Large stories increase the risk that your team will deliver nothing at the end of the iteration.
• Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.
• Smaller stories are easier to review when you use GenAI to aid in your development.

So what is my guidance for new Scrum teams when they’re trying to decide on Story size? Two people for half an iteration. Why two people? Because most stories require collaborative effort and I want to encourage pairing/collaboration. Especially when working with GenAI, collaboration is important. With GenAI, most problems tackled have a larger surface. Having more people thinking through what is being asked for is better.

Why half an iteration? Because any larger makes it quite likely that the story will not be completed in a sprint. Even stories of this size are still a bit large, and they shouldn’t commit to more than one of these per sprint. If you’re still using Story Points, most teams I’ve met find 13 point items to be hard to digest. (See our Estimation and NoEstimates glossary entries for more.)

All this suggests that most stories should be small enough that the team can finish five to ten of them in a Sprint. By finish, I mean tested, usability reviewed, security audited. Truly done. If your team likes Story Points this is the 1-3. Items that are larger belong further down the Product Backlog and should be split into much smaller parts before the team attempts to commit to them.

But That’s Really Small

If we’re working in bite size chunks, how do we get any meaningful work done? How do you slice them so small? Part of the problem is a frequent misunderstanding around value in stories. The ‘V’ in INVEST stands for valuable, many people assume that equates to business value or a feature that you can sell for a dollar. When we combine user stories together, they represent features that customers will pay for. But on their own they’re too small for that. Instead value refers to the point of view of the user for whom the story was written in the first place.

So the hard part: how do you slice? Some simple ideas:

• CRUD (Create, Read, Update, Delete) boundaries
• Acceptance criteria – often the acceptance criteria will give a good hint about where the seams are. Example Mapping is a fast way to surface them.
• Happy Path – many stories have exceptional conditions, consider splitting them out
• Simple versions of an algorithm. With a complex algorithm and complex UI, it might be worthwhile to do a simple version of either first and then fill in the detail in the next story. Sometime this can come from making some elements constants instead of looking them up or calculating them

What not to do: Split along architectural or technology boundaries, as this will create stories that don’t deliver value to an end user.

Can GenAI Help?

Less than the vendors want us to believe. The more of the work we hand off, the less we understand the product we’re building. That understanding is an important part of why we slice in the first place.

1. Always start with a conversation among the team members; remember part of the value of slicing is a common understanding.
2. Write down everything you’ve considered in terms of splitting, including the acceptance criteria. Usually this step will provide the answer for you.
3. Ask the GenAI to ask you more questions on the item. Avoid: Asking the tool to slice the Story for you.
4. Still stuck? If the question is technical understanding, consider a Spike. Business understanding? Do more research with the customer/stakeholders.

Notice that only step 3 uses the tool.

When slicing stories imagine using a scalpel and not a butcher’s knife. Go create some story sashimi.