How to split user stories: patterns that work

To split a user story, cut it into thinner stories that each still deliver something a user can see, try and react to. Each slice runs through every layer it needs, from screen to database, so it can be finished and released on its own. Then estimate the new stories separately and let the product owner order them.

The hard part is knowing where to cut. This guide gives you ten patterns that work for most stories, the INVEST test for a good result, and a worked example that turns a 21-point story into slices a team can actually finish.

When should you split a user story?

Split a story when it is too big to finish comfortably in one sprint, or too vague to estimate. The Scrum Guide sets the outer limit: items that can be Done within one sprint are “deemed ready for selection in a Sprint Planning event”. In practice you want stories well inside that limit, so watch for these signals during backlog refinement:

• The estimate is above your team’s ceiling, often 8 or 13 points.
• Votes spread widely, such as a 5 and a 34 for the same story.
• The acceptance criteria run to a dozen bullets, or the title contains “and”.
• Several kinds of user are involved, each with different needs.
• Nobody can describe a first version worth showing to a user.

A good target comes from Bill Wake’s INVEST checklist, published in 2003: a good story is Independent, Negotiable, Valuable, Estimable, Small and Testable. Splitting is mostly about Small and Estimable, but the other four letters are what stop you splitting badly.

Split vertically, not horizontally

The most common splitting mistake is cutting by technical layer: one story for the database, one for the API, one for the screens. None of those delivers anything a user can try or anyone can test end to end, and the risky integration work all lands at the end.

A vertical slice cuts through all the layers to deliver a thin piece of working behaviour. Compare two ways of splitting “Customers can track their delivery”:

Each vertical slice could ship on its own, and the first is valuable even if the map is never built. That option, to stop once enough value is delivered, is one of the best reasons to split at all.

10 patterns for splitting user stories

These patterns overlap with two well-known references: the Humanizing Work guide to splitting user stories, and Mike Cohn’s SPIDR (spikes, paths, interfaces, data and rules). Try two or three on any big story, and keep the split that gives the product owner the most choice.

1. Workflow steps

If a story describes a process, build a simple end-to-end version first and add steps later. “Employees submit expense claims for approval” could start with claims under £50 approved automatically, then add manager approval, then a finance check for claims over £500.

2. Business rule variations

Many stories hide several rules. “Customers can use discount codes” might cover percentage discounts, fixed amounts, free delivery, minimum spends and one-use-per-customer limits. Start with percentage discounts and add each rule as its own story.

3. Happy path, then unhappy paths

Build the path where everything goes right, then handle what goes wrong. For “Users can reset their password”, the first slice sends a reset link and lets the user choose a new password. Later slices handle expired links, unknown email addresses (without revealing whether an account exists) and repeated failed attempts.

4. Data variations

Support the simplest data first. A store finder might accept full UK postcodes first, then town names, then partial postcodes. A public service form might launch in English, with Welsh added as a separate story.

5. Interfaces and platforms

Deliver one interface or platform, then extend. “Book a meeting room” might start in the web app and come to the mobile app later. A date field might start as a validated text box, with a calendar picker as a later story.

6. Operations (create, read, update, delete)

Stories with “manage” in the title usually hide several operations. “Customers can manage saved addresses” splits naturally into adding an address, viewing saved addresses, editing one, deleting one and choosing a default.

7. Simple core first

Find the simplest version that is still useful, and move each complication into its own story. A restaurant booking search could start with an exact date, time and party size, with flexible times and nearby alternatives added later.

8. Major effort first

Sometimes the first variation carries most of the work and the rest are cheap. Accepting the first card scheme means building the whole payment integration; adding a second scheme afterwards is small. Split so the big piece stands alone and the rest can be estimated honestly.

9. Defer performance

Make it work, then make it fast. A monthly sales report could first run on demand in a couple of minutes with a progress message, and a later story could bring it under five seconds. Only defer a quality such as speed when the slower version is still acceptable to users and your Definition of Done allows it.

10. Spikes

When a story is big because nobody knows how to build it, split off a short, timeboxed investigation. “Can we import new starters from the HR system’s API, and how often can we call it?” is a good spike: a clear question and a limit of, say, two days. A spike delivers an answer rather than a feature, so use it sparingly and only after the other patterns have failed.

Worked example: splitting a 21-point story

A team building a workplace collaboration app is refining this story:

As an account admin, I want to import our staff from a spreadsheet, so that I don’t have to invite 300 people one at a time.

The acceptance criteria ask for CSV and Excel files, validation of every row, a report of errors, handling of people who already have accounts, roles and teams set from the file, invitation emails and support for files of 10,000 rows. The planning poker round comes back like this:

• 13
• 21
• 21
• 34
• ?

The team settles on 21, but that number is a warning as much as an estimate. With a velocity of about 30, one story would take most of the sprint, and the spread of votes says people are picturing different things. So they split it:

Three things happened, and all of them are typical:

• The parts add up to 24, not 21. Splitting surfaced work the big number was hiding. That is a better estimate, not a worse one.
• The product owner gained choices. The first three slices (11 points) already save an admin hours. Excel support and very large files can wait until customers ask for them, and might never be needed.
• Feedback arrives sooner. The first slice can be in a customer’s hands within days. Until the invitation slice ships, admins send invites from the existing user list, which is clunky but works.

How to run a splitting conversation

1. Read the acceptance criteria aloud. Every “and”, “or” and bullet point is a possible seam.
2. Find the core. Ask what the smallest version is that a real user could use and react to.
3. Try two or three patterns. Prefer the split that lets the product owner defer or drop something. If every slice is essential, the split hasn’t created many options.
4. Check each slice against INVEST. Could it be released on its own, does it deliver value, and could someone test it?
5. Estimate each slice. Run a fresh round per slice rather than dividing the original number. Our guide to running a planning poker session covers the mechanics.
6. Let the product owner order them. Each slice takes its own place in the backlog, and they don’t have to stay together.

Common splitting mistakes

• Splitting by layer or by specialism. A “front-end story” and a “back-end story” are tasks dressed up as stories.
• Part 1 and part 2. Splitting by time (“the first half of the work”) produces pieces with no value of their own.
• Leaving the risk until last. If the integration is the scary part, put a thin version of it in the first slice.
• Slicing too thin. Twenty one-point stories carry real overhead in tickets, reviews and demos. Aim for slices that take a few days, not a few hours.
• Splitting to look busy. Splitting raises the total points and the number of tickets, but it doesn’t get more work done. If velocity jumps after a splitting drive, check whether anything more actually shipped.

How small is small enough?

There is no universal number, but there are useful limits. Bill Wake’s original INVEST article suggests stories typically represent at most a few person-weeks of work, and notes that some teams keep them to a few person-days. For two-week sprints, the second figure is the better target.

A practical test: the team should finish several stories each sprint, so that one surprise doesn’t sink the sprint goal. A team with a velocity around 30 that caps stories at 8 points will complete at least four stories a sprint, and usually more. If a single story regularly takes more than half the sprint, it is too big, whatever its story points say.

On planningpoker.org After each reveal, SprintPoker shows the average, median, most common vote, range and a distribution chart. A range from 5 to 34 is usually a story asking to be split, so pause there before anyone picks a number.