Splitting a big story
In short: A big story is cut vertically: every piece goes through everything it needs and gives something someone can try. The patterns hint at where to cut: by steps, rules, data, complexity, quality or operations. A layer (frontend, backend, database) is not a story.
Problem
Three weeks and nothing to show
The story is "As a customer I want to return a product and get my money back." It is big, so the team divides it: one person builds the returns screen, another the database records, a third the refund.
After two weeks the screen is ready, but it does nothing. The database is ready, but nobody can see it. The owner asks "can I see a return?" and the answer is "not yet". In the third week everything is connected, and that is when QA finds that the 14 days are counted from the order, not from receiving the goods.
The pieces were small. But none of them could be tried on its own.
The idea
Vertical, not in layers
Think of the story as a layer cake: screen, processing, database. Splitting by layers cuts the cake horizontally. You get a whole layer of cream, and nobody can eat it as cake.
A good split cuts vertically: every piece has as much of every layer as it needs and gives something someone can try. For returns, the first vertical piece is "the customer requests a return within 14 days of receiving the goods". It is small. But the owner can see it in the first week, and QA can check the 14-day boundary straight away.
This is called story splitting: a big story is cut into smaller ones, each of which is still a story by INVEST.
More precisely, if you are curious
The cake metaphor is old: Bill Wake already uses it in his article on INVEST. Such a piece is called a vertical slice, and splitting is also called slicing.
The idea
Where to cut
There is no single right cut, but there are patterns that come up again and again. Here are six, with the shop:
| Pattern | When it fits | In the shop |
|---|---|---|
| By workflow steps | the story is a process with several steps | returns: request, parcel back, warehouse, money |
| By business rules | one action, many rules | the final total: delivery, promo code, loyalty, which applies |
| By data variations | the same path, different data | a product in one size, then with size and colour |
| The main case first | there is a main case and many complications | search by name, then filters and suggestions |
| Make it work first, then the quality | a requirement for speed or load | payment, then payment with 2,000 customers at once |
| By operations | "manage" hides several actions | promo codes: create, view, change, stop |
The first question is: why is the story big? Because of the steps, the rules, the data? The answer suggests the pattern.
More precisely, if you are curious
The patterns here follow the list most often cited in practice: Richard Lawrence's "Patterns for Splitting User Stories" (2009). Another well-known set is Mike Cohn's SPIDR: Spike, Paths, Interfaces, Data, Rules.
The last pattern is often called CRUD, from create, read, update, delete. In the shop "delete" becomes "stop", and you will see why in the exercise.
Try it
Which pattern?
Try it
Split the return
Choose the pattern, then the pieces of the split in the order they are built.
As a customer I want to return a product I do not like and get my money back.
Step 2: Which pieces, in what order?
Add the pieces that form the split and put them in order: the first one is done first.
The pieces
The split
Pattern
- By workflow steps: A return goes through several steps: the request, sending the parcel back, the warehouse receiving it, the money. Each can be built and shown to the owner on its own.
The model split
- The customer requests a return of a delivered order within 14 days of receiving it
- The customer gets instructions on how to send the product back
- The warehouse receives the parcel and the order becomes returned
- The shop refunds the customer
A return is big because of the steps, not the rules. Every step is a story: after the first one the customer can already request a return, and the owner sees how many people do it. The screen and the database are not pieces; they are parts of every piece.
The idea
Why not by layers
Splitting by layers looks sensible, because that is how the team is organised: one person builds screens, another the processing. But it costs a lot:
- Nobody can try it. The owner sees something only when every layer is ready. If the story is wrong, they find out last.
- It cannot be checked. The criteria of the story ("within 14 days of receiving the goods") are about behaviour, not about a screen or a database. QA waits until the end.
- The risk is at the end. The layers meet at the end, and that is where the mismatches show up.
- It is not valuable by INVEST. No piece brings anything to anyone outside the team.
Layers are tasks inside the story. Developers build them, but the story counts as done when the whole vertical piece works.
The idea
How to tell a split is good
- Every piece is a story. It has a role, a goal and a benefit, and passes INVEST.
- The first piece brings the most. The most value or the most learning. If the first piece is "preparation", you are cutting wrong.
- The pieces do not overlap. None is inside another.
- Together they cover the big story. Or at least what of it is really needed.
The last point matters. Often after a few pieces the owner says "that is enough". The remaining pieces are never built, and that is not a failure. That is the split doing its job.
Exercise
Split the stories
1. The final total. The story about the total before payment.
Choose the pattern, then the pieces of the split in the order they are built.
As a customer I want to see the final total with delivery and discounts before paying, so that I know how much I will pay.
Step 2: Which pieces, in what order?
Add the pieces that form the split and put them in order: the first one is done first.
The pieces
The split
Pattern
- By business rules: The total is one, but the rules are several: delivery, the promo code, loyalty, and which applies when there are two. Each rule can be built, shown and checked on its own.
The model split
- The total with delivery: free from 50.00 €, otherwise 4.90 €
- The total with a promo code: 10 %, not on discounted products
- The total for a loyal customer: 5 %
- Promo code and loyalty together: the bigger discount applies
Every rule is a story that can be checked on its own: "a cart of 50.00 €, delivery is free". The rule "the bigger one applies" is last, because it makes sense once both discounts exist. The other three can come in any order.
2. The promo codes. Marketing's story.
Choose the pattern, then the pieces of the split in the order they are built.
As a marketing employee I want to manage the promo codes so that I can start and stop campaigns without a developer.
Step 2: Which pieces, in what order?
Add the pieces that form the split and put them in order: the first one is done first.
The pieces
The split
Pattern
- By operations: create, view, change, stop: "Manage" hides several separate actions. Each is a story the employee can try on their own.
The model split
- The employee creates a new promo code with a validity period
- The employee sees the codes and how many times each has been used
- The employee stops a code before its period ends
- The employee changes the validity period of a code
Creating comes first, because without a code there is nothing to view, change or stop. The "delete" of CRUD becomes "stop" here: a used code has to stay, because accounting reconciles the discounts per code. The need of one stakeholder changed the pattern.
Test