Story Splitting Q&A

The “Humanizing Work Guide to Splitting User Stories” is the comprehensive resource on the topic, but it’s LONG. So, here’s some bite-sized story splitting Q&A for when you don’t need the full 6000-word guide…

What’s a user story?

A description of a change in system behavior from the perspective of a user. It’s about structuring your work to give users more and more capability vs organizing work around technical tasks.

What makes for a good story?

Among other things, look for a clear WHO, WHAT, and WHY that represent real value for actual users. Bill Wake’s INVEST acronym is also helpful.

How big should a user story be?

As they approach the top of the backlog, I like stories to be small enough that 6-10 could fit in a sprint. This means smaller teams with shorter sprints would have smaller stories. It’s about how much capacity you bet on one story.

When should we split user stories down to this size?

About 1-2 sprints from the top of the backlog. See our PO Board video for more on how much detail to include on different time horizons.

How much detail should be in a user story?

Stories are placeholders for conversations—capture enough info to support the next conversation, then write down what you talked about & decided so you don’t have to talk about it again. More complex stories = info emerging later.

When people say a story should be a “vertical slice,” what’s that?

“Vertical slice” means a story should cut across all the parts of a system that need to change to achieve the desired outcome for the user. A story isn’t just a change to one architectural layer.

How do I know a story is ready to split?

(1) When it’s bigger than the 6-10/sprint size for your team. (2) When it represents an actual increment of value for a user. To get #2, you might have to combine pieces before splitting.

How do I split a workflow?

Don’t go left-right, step-by-step; that’s the worst way to do it. Instead, look for a thin slice through the whole workflow. If that’s too big, look for a thin slice through the complex part first.

How do I split a story about managing a thing?

Words like “manage” suggest multiple operations. List out the different verbs involved in “managing” & make each of those its own story. Do the most complex first. It’ll teach you the most.

How do I split a story with business rule variations?

When there are multiple paths through a story w/ different data or w/ user decisions, you have biz rule variations. Each of those variations can become a story. Get 1 working first rather than serval partly working.

When should I use a spike?

Probably way less often than you do. Spikes are designed to probe tech complexity by building a thin slice to learn (which then gets thrown away). It’s not a magic agile word for “do all the research & design first, then build it.”

How do I know if I’ve found a good split?

(1) It helps you find something low-value you don’t need to build. (2) It generates roughly equally-sized small stories. (3) There’s a small but complex one to tackle first.

How can my team get good at splitting?

Start by practicing the patterns on past hard-to-split items to learn what the patterns look like in your domain. Then practice on future stuff. Three 1-hr practice sessions is usually enough to start getting fluent.


And when you do need a comprehensive resource to help your team split user stories more effectively, check out the full “Humanizing Work Guide to Splitting User Stories,” including the popular story splitting flowchart.


Here’s a Twitter version of this if you want to share it there:

Last updated