Splitting a User Story Without Losing the Value

One story from a published case, run through nine splitting patterns. Which slices keep the point, which lose it, and what each has to carry.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources - a published returns policy, help centre articles, ten public complaint threads I selected myself, consumer law and a walk through the published customer journey. No client, no interviews, no team and no sprint. I run the story at its centre, REQ-014, through nine published splitting patterns. Every split and every verdict below is mine [MINE], and you can redo them from the case.

Splitting a user story vertically means cutting it into pieces that each still run end to end and each still change something a user would notice. The test that a split kept the value is narrower than that: every piece needs a "so that" of its own, and that "so that" has to make part of the original problem untrue.

In short

• A vertical slice can touch every layer and still lose the point. Here, the split that loses it most cleanly looks the most like a feature.
• Some requirements must travel with any slice that touches what they guard. The case writes four of those lines down; I call them tethers.
• Nine patterns on REQ-014 give four usable splits, one that loses part of the point and four that do not apply [MINE]. The case had already made two of the four under other names.
• The thinnest slice that keeps the point defers the automated pre-check, against the register's own priority. That makes it a proposal for the product owner, not a finding.

What does "vertical" actually promise?

Bill Wake's INVEST checklist, published in 2003, puts the value test in its third letter: "A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer." The same article treats a story as a cake with layers: "the best way is to slice vertically through the layers".

Richard Lawrence and Peter Green's guide to splitting user stories defines the vertical slice as "a work item that delivers a valuable change in system behavior such that you'll probably have to touch multiple architectural layers to implement the change". It lists nine patterns: Workflow Steps, Operations (e.g. CRUD), Business Rule Variations, Variations in Data, Data Entry Methods, Major Effort, Simple/Complex, Defer Performance, and Break Out a Spike.

Both sources warn against cutting by layer. In a requirements register there is a second danger: a slice can cut through every layer, run end to end, and still leave the problem it was written for exactly as true as before.

The story, and what it pulls behind it

REQ-014, as the case writes it:

As a customer who received a damaged item, I want to start a refund without calling support, so that I get my money back within the promised window.

Three acceptance criteria: photo upload of up to 3 files at 10 MB each [MINE]; a decision recorded within 48 hours [MINE] of the form timestamp, with escalation under REQ-015 if none is recorded; partial refunds only above 40 EUR [POLICY] (BR-11).

By the register's own measure this story needs no split: template 3 says "at seven you are describing a feature, not a requirement", and REQ-014 has three. The size sits in what it pulls behind it. Four other entries tie themselves to it or to the change it delivers:

Those are tethers: lines that have to travel with whichever slice touches what they are tied to. Section 4.1 says the same from the other side: "I would not cut REQ-017 or REQ-018, because both are the safety rails on the change that moves money earlier."

How do you know a slice kept the point?

Three questions per slice, each answered from a line in the case.

1. Does it have its own "so that"? Template 3: "If the 'so that' repeats the 'I want' in other words, the value is missing." A slice gets a new "so that", not a copy.
2. Which line of the problem does it make untrue? Section 1.3: "A damaged-delivery case that lacks sufficient evidence at the first call has no named owner and no due date." A slice that leaves both halves true has shipped something, but not the point.
3. Which tethers ride with it? Photographs bring REQ-016, a decision before the parcel arrives brings REQ-017, automation brings REQ-018.

The nine patterns, run on REQ-014

Four keep the point, one loses part of it, four do not apply. That is a count of nine patterns on one story, not a rule about stories.

Two of the four usable splits were already in the case under other names. The Business Rule Variations split is the fallback on OQ-05: if nobody decides by 30 April 2026, partial refunds go "out of release 1, threshold conversation moves to release 2". The Simple/Complex split is section 4.1: "The obligation stays, the build shrinks." Neither was written as a split. Both are one: a variation moved out, with the rule held in place.

Which split looks vertical and loses the point?

A sharper loss than the Data Entry row comes from a split none of the nine patterns produces on purpose: the form ships, the escalation waits.

On the face of it this slice is perfect. It touches every layer, from the screen to storage, and it is the half of the story that is easiest to show. Its "so that" even works: describe the damage once, with photos, at whatever hour the parcel was opened (OBS-01 to OBS-03).

Now ask the second question. After this slice ships, a case the person on the other end cannot decide still has no named owner and no due date. Both halves of the problem sentence are untouched. The slice also cannot pass REQ-014's own criterion 2, which hands the undecided case to REQ-015, so the story would ship without it. That criterion is where "within the promised window", the parent's "so that", lives.

The split kept the part that was easiest to show and removed the part the case was written for.

And the split that keeps the point but loses its anchor

The mirror image: escalation first, form later. A named owner and a due date on every undecided case, before any self-service exists.

This slice makes both halves of the problem sentence untrue. But REQ-014 criterion 2 anchors the 48 hours to "the timestamp on the submitted form, not the moment an agent opens it", and that wording is the fix for RL-02, the developer's objection on 2 April 2026: "Under 48 hours from what moment?" Without the form, there is no form timestamp. The slice needs a new start event, and the case has not written one.

So this slice reopens a closed objection. It can ship only after someone writes the start event into the criterion (scorecard check 13) and accepts what that does to a parcel opened on Friday evening, since the phone line runs 09:00 to 17:00 on working days (OBS-02).

The thinnest slice that keeps the point

Putting the usable rows together, the smallest release I can build from the case without losing the point is this [MINE]:

• Ships: the form with photos, a person deciding, escalation at 48 hours from the form timestamp to a named individual (REQ-015, all three criteria), the goods-in reopen (REQ-017), and retention with deletion done by hand (REQ-016, the cut 4.1 names).
• Waits, together: the automated pre-check and REQ-018. The tether runs both ways, so the guard rail waits with the automation it guards.
• Waits: partial refunds, on the OQ-05 fallback. Multi-item orders, behind the per-order-or-per-item question.

This contradicts the register: REQ-018 is "Must have, release 1", and the pre-check is part of change 1 as the case draws it. The stakeholder map gives the release slot to the e-commerce product owner (row 5, approval right), so the slice is a question for that role, not something an analyst ships by rewording a backlog.

It also needs one sentence the register does not have. REQ-014 criterion 3 says that at or below 40 EUR the refund is "full or refused, never partial". If partial refunds wait, the slice has to say what an order above 40 EUR gets meanwhile, or the team decides it during build.

The split sheet, filled in

One sheet per slice. This is the first slice above, filled from the case.

The "tethers" row stops a guard rail being left behind. The "line the slice needs" row stops the team filling a gap in build.

The split sheet, blank

Where does this method stop?

It needs a register that writes its tethers down. If yours does not, start one step earlier: for each requirement, write what it is a consequence of into its source field, the way REQ-016 says "Consequence of REQ-014". It also says nothing about size. The case has no team and no estimate, so whether a slice fits a sprint is for the people who would build it.

When a split turns into a cut, the scope piece has the next move. Ordering slices is argued in MoSCoW or WSJF, and the criteria every slice inherits are in acceptance criteria that survive. The full register is at /case and as a template, the tags are on the method page, and checks 01, 02 and 13 of the scorecard are the ones a split story has to pass again after every cut.

All field notes · The portfolio guide · More in Requirements That Survive Review