Cut Stories Thinner

Part eight of the product owner toolbox. In the last part we wrote a good user story. Most stories don’t start out that good. They start out too big.

Splitting means dividing a story into smaller, consistent pieces that can be estimated, built and tested within one sprint. The reasons vary: the sprint’s capacity, the story’s complexity, a part of it that’s still unclear.

There’s one rule: every piece still has to deliver some of the value. Split the story vertically, through every layer of the system, so that each piece is something a user can actually use. A thin slice that works end to end beats a thick slice that’s only finished in one layer.

How to split

1. Check the story’s size and complexity.
2. Pick a splitting pattern, or a combination, and cut the story into two or more stories.
3. Check every new story:
   • Is it small enough for one sprint?
   • Is it simple enough to estimate?
   • Can it be tested?

In practice you’ll usually combine several patterns.

Eight patterns

These come from Richard Lawrence’s work on story splitting. Each one is shown on a story from the leave tool.

1. Workflow steps. If a story contains a whole workflow, split it into steps, or into the happy path first and the exceptions, loops and branches later. Leave tool: “Request leave with approval by the team lead and HR” becomes “approval by the team lead”, followed later by “HR confirms”.

2. Business rule variations. If a story has several business rules, prioritise them and build them one by one. Leave tool: full days first. Half days next. Rules for carrying over days at the end of the year later.

3. Data variations. If a story has to handle different sets of data, identify them, start with one and add the others over time. Leave tool: holiday first. Then sick leave, unpaid leave, military service and parental leave, each a story of its own.

4. Interface variations. If a story talks to several interfaces, or offers several, separate them and add them one by one, for example web before mobile, or iOS before Android. Leave tool: approval in the web app first. Approval from a link in an email next. Approval in the team chat later.

5. Major effort. If one part of the story causes most of the effort, put that part in its own story and build it first. The stories after it become cheap. Leave tool: “show absences in the team calendar” pays for the calendar component once. “Show pending requests” and “mark understaffed weeks” reuse it.

6. Simple or complex. If the story has a simple core that delivers most of the value, build that core first and collect the edge cases in one or more separate stories. Leave tool: a request within one calendar year first. Requests across New Year, with two different balances, later.

7. Defer performance. Pull performance, security and usability requirements out into separate stories. Leave tool: “the team calendar loads in under a second for 300 people” becomes a story of its own. The important word is story. Deferring a requirement is fine. Forgetting it isn’t. Name it and put it in the backlog.

8. Operations. If a story contains create, read, update and delete operations, build them one at a time. Leave tool: submit a request. Cancel a request. Change the dates of a pending request.

The split that doesn’t work

The split teams reach for first is by layer: “backend for leave requests”, then “frontend for leave requests”, then “tests”. None of these delivers anything on its own, none can be accepted by the product owner, and the value only shows up when the last one is done. If the sprint ends in between, you have three half-finished things instead of one finished thing.

The other trap is the “research” story with no result. If you need to find something out, time-box it and agree beforehand on what the answer will decide.

Next

The backlog is full of small, valuable stories now. Next time: how to keep it that way, and how to prioritise it with the people who disagree with you in the room.