Story splitting
Splitting is the skill most in demand when working with stories, and the one least often taught. Before looking at how it is done, it helps to understand why: a small batch shortens the time between making a decision and knowing whether it was a good one, and that cycle is the only thing that turns delivery into learning. Donald Reinertsen systematized this for product development, and the DORA program backs it up with data year after year, placing working in small batches among the capabilities associated with high performance.
Three benefits follow from this: earlier feedback, less risk per delivery, and the option to deprioritize or discard a part when it turns out not to matter. This third one is what best distinguishes a good split from a bad one.
The discard test. A split that doesn't let you give up any of its pieces hasn't split anything: it has spread the same work across more cards.
How Much, When, and How Far
The figures in circulation are heuristics from different eras (from "a few person-weeks" in the original INVEST text to "half a day to two days" in teams with frequent deployment). Rather than adopting one, it is better to replace it with the team's own measure: look at how long the last 30 items took and ask, when facing a new story, "Is it like the ones we finished in less than three days?" The Kanban community separates two ideas that are often confused: sizing to the service level expectation (right-sizing), which is useful, and making all sizes equal (same-sizing), which is a ritual.
There is also a lower limit: when the piece can no longer state what changes for someone, it has stopped being value and has become an implementation detail formatted as a story. The response then is the reverse of splitting: recombining.
The right time to split is one or two cycles before the story reaches the top of the backlog. Splitting earlier is wasted work if the goal changes; splitting during planning is too late, because the conversation that uncovers the cut doesn't fit into that slot.
The Vertical Slice
A vertical slice delivers an observable change in behavior and cuts through every layer needed to achieve it: if it needs an interface, a service, and data, all three go in. The slice can be wafer-thin (a single case, a single data type) and still be vertical as long as someone can use it and notice it. This is the "end-to-end" property that Bill Wake added to INVEST in 2021.
How do you recognize it? A single question is enough: could someone outside the team try this and say whether it works for them? If the answer is no, the slice is horizontal, even if the card uses a story template.
Layer-based slicing and legitimate technical slices
The most widespread splitting mistake has a recognizable shape: slicing by technical layers. It produces three pieces (interface, services, data), none of which can be delivered or evaluated on its own, and all three must be completed before anyone notices anything. It is the first of the five splitting mistakes documented by Mike Cohn.
Not every technical split is illegitimate. Three are justified, provided they are stated honestly and without pretending to be user value (see Technical story):
- The spike, when the uncertainty concerns knowledge rather than scope: buying information through time-boxed work with an explicit question. It is a last resort, not something to attach to every story.
- The enabler story, work that prepares the ground for several later stories (a migration, an integration). Outside SAFe, it is best stated plainly, with its beneficiary and its economic justification.
- The walking skeleton (Alistair Cockburn): a minimal implementation that performs a function end to end across all components, used for the first slice of something large. The tracer bullet (Hunt and Thomas) is the same idea seen from the code. Gojko Adzic adds a practical corrective: putting the skeleton on crutches, that is, completing the slice with whatever it takes (data loaded by hand, a manual process behind the scenes) so that someone can actually use it rather than just watch it work.
The pattern catalog and its origins
Patterns are the tools of the trade, and their value lies less in the list than in knowing which signal in the story suggests each one. The unified catalog below is an editorial synthesis of patterns established one by one, and it is worth recalling the warning in the Agile Alliance glossary: there is considerably less consensus on how to split than it might seem.
When the story describes a flow
- Workflow steps (Humanizing Work). The first slice should go through the entire flow in the simplest possible way; subsequent slices flesh out the steps. Delivering the first step in full produces useless pieces.
- Paths and interfaces (Wake; Cohn). Each alternative path (by card or by bank transfer; web or mobile) is a slice. Signal: the story hides an "or."
When the story hides variety
- Business rule variations. The general rule first, the exceptions later. Signal: "unless," "except," "depends on."
- Data variations. Each data type is a slice. Signal: enumerations.
- Operations. Create, view, update, and delete are rarely worth the same. Signal: the catch-all verb "manage."
- User segment. Serve a narrow segment first. Signal: a user described in a generic plural.
When complexity is unevenly distributed
- Simple first, complex later. Signal: "80% of the cases are the same."
- Major effort isolated. Separate the part where the work is concentrated. Signal: an estimate dominated by a single item.
- Deferred system qualities. First it works, then it works fast (or accessibly, or at scale). Legitimate only if made explicit and given a date.
- Capacity and volume. Start with a limit and expand it. Signal: a volume requirement that multiplies complexity.
When what's missing is information or value
- Manual before automated. Solve it with a person behind the scenes, and automate once you know what to automate.
- Learning before earning (Adzic). Deliver first the part that teaches you something, even if it doesn't generate revenue.
- Extract a spike. When uncertainty prevents sizing.
SPIDR, a mnemonic for five. Mike Cohn grouped the most productive patterns into a handy acronym: Spike, Path, Interface, Data, and Rules. It works as a first pass before turning to the full catalog.
Readers coming from Scrum Manager's basic handbook "Historias de usuario" [User Stories, in Spanish] will recognize its eleven strategies here under different names: splitting by steps, by rules, by data types, by operations, and by roles corresponds to the flow and variety patterns; happy path and alternative path is a case of rules and paths; input options or platforms is the interfaces pattern; test cases or scenarios is equivalent to data variations; optimize now or later is deferring system qualities; and "strategy zero," building a spike, is the extract-a-spike pattern.
From Pattern to Cut: Choosing and Judging
Before splitting, the precondition is counterintuitive (Humanizing Work): the story must satisfy INVEST except for the S, the one for size. If another property fails, splitting fixes nothing; and the one that fails is almost always value. When a story resists splitting, the missing property is the V, not the S: you need to recombine until you find the observable change, and split that.
The procedure has three moves: identify the signal; apply two or three compatible patterns, without stopping at the first one (the second or third split is usually better); and compare the candidates. A split is judged against six criteria—it preserves value, is verifiable, allows deprioritizing, yields pieces of similar size, teaches something, and is sufficiently independent—of which the third and fourth are the most discriminating. And there is a test that rules out false splits in a second: if all the pieces are mandatory to complete the large story, nothing has been split.
For stories that resist every pattern, Humanizing Work proposes a three-step meta-pattern: find the core complexity, identify the variations around it, and reduce them to one for the first slice. Adzic's hamburger method is useful with teams that can only think in layers: list the layers, list the quality options for each one from lowest to highest, and choose a minimum level from each to form a complete first slice. Every cut introduces dependencies, which are handled in the order of healthy refinement: make them visible, eliminate the avoidable ones, and manage the unavoidable ones.
Practice. You learn splitting by splitting. The canonical exercise is Elephant Carpaccio (Cockburn, with Henrik Kniberg's facilitation guide): breaking a small feature into some twenty vertical slices. About three hours of deliberate practice is enough to build fluency.
Story splitting and AI
AI assistance works best when critiquing a split rather than proposing one: asking it to review a story or a map the team has already produced brings to light variants no one considered, slices with no outcome that can be stated, and dependencies no one saw, and all of that is material for the next session.
Generating splits "from scratch" with a model produces plausible pieces that are disconnected from the product's real value, because the model knows neither the users nor the goal. The decision about what to split, what to postpone, and what to discard remains a product decision, with an identifiable owner.
Common mistake
Slicing by layers and calling it splitting. It produces three pieces (interface, services, data) that no one can assess separately and that must all be delivered before anyone notices anything. The alternative is the vertical slice: a slice, however thin, that cuts through the system and that someone outside the team can try out and say whether it works for them.
Resources
🏦 Skill User storiesState of the art and development guide · Skill Arena
📄 Historias de usuario v.5.0 [User Stories v.5.0, in Spanish]Free download · Scrum Manager · Jan 2026
📄 Scrum Master en equipos con IA v.1.0 [Scrum Master in Teams with AI v.1.0, in Spanish]Free download · Scrum Manager
📄 Cómo se crea una historia de usuario [How a User Story Is Created, in Spanish]Scrum Manager Blog · Jan 2023
References
- Cohn, Mike. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
- Reinertsen, Donald G. (2009). The Principles of Product Development Flow. Celeritas Publishing.
- Cockburn, Alistair. (2004). Crystal Clear. Addison-Wesley.
- Hunt, Andrew; Thomas, David. (1999). The Pragmatic Programmer. Addison-Wesley.
- Wake, Bill. (2003). "INVEST in Good Stories, and SMART Tasks."
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.