Splitting Stories That Come In at 8 Points or More

The votes come back: 8, 8, 13, 8. It's tempting to write down an 8 and move on. The team agreed, more or less, and the ticket is big but not outrageous.

This post argues for a simple rule instead: an 8 is a question, not an answer. When a ticket comes in at 8 or more, the first thing to ask is whether it should be two or three smaller tickets. Often it should, and splitting it well is a skill you can learn.

Why 8?

There's nothing magic about the number. What matters is how big a ticket is compared with your sprint. Richard Lawrence and Peter Green's guide to splitting stories gives a useful rule of thumb: by the time a story reaches the top of the backlog, "you should be able to fit 6 to 10 into a sprint." They note it's a ratio, so it scales with sprint length, team size and velocity^[1].

Take a team that finishes about 30 points a sprint. An 8 is more than a quarter of their sprint, so they could fit only three or four tickets like it. If one of those slips, a quarter of the sprint slips with it. For most teams, 8 is about where a ticket stops fitting the 6-to-10 rule.

There are two more reasons:

• The scale is telling you something. On a Fibonacci scale, the gaps widen as the numbers grow. Voting 8 doesn't mean "exactly 8". It means "bigger than 5 and we're not sure by how much." See story points and the Fibonacci scale.
• Big tickets hide disagreement. An 8 that everyone agrees on can still mean four people picturing four different pieces of work. Large tickets are where estimates disagree most, as covered in why estimates disagree.

What a good split looks like

Bill Wake's INVEST checklist, from 2003, is still the best short description of a good story: Independent, Negotiable, Valuable, Estimable, Small and Testable^[2]. Splitting is about Small, but a split that breaks the other five letters isn't worth having.

The most common mistake is splitting by layer instead of by slice:

The layer split looks tidy, but no ticket in it is valuable on its own, none can be tested by a user, and the testing all lands at the end. Each slice, on the other hand, is something a customer could use, and each can ship on its own.

This matters even more for teams that estimate per role. If Frontend, Backend and QA each size the ticket, it's tempting to split it into a Frontend ticket, a Backend ticket and a QA ticket. Don't: the per-role estimates already give you that breakdown. Split the work into slices, and let each slice carry all the roles it needs.

Five ways to find the split

Mike Cohn's SPIDR gives five places to look for a split: Spikes, Paths, Interfaces, Data and Rules^[3]. Here they are, applied to one ticket: "Let customers export their invoice history as CSV," which the team voted 13.

Spike: take the research out

Part of why the ticket is big is that nobody knows how to export ten years of invoices without timing out. Pull that research into its own time-boxed spike ("two days to find out how to stream large exports"), and the remaining ticket gets smaller and easier to estimate.

Paths: build one route through it first

There are several routes through an export: this year, a custom date range, all history. Build the simplest path, this year's invoices, first. The other paths become their own tickets.

Interfaces: one interface at a time

A download button in the web app is one interface. An API endpoint or a scheduled email is another. Ship the button first.

Data: start with the simple data

CSV first, Excel later. Or: small accounts download straight away, and large accounts, which need a background job and an email, come in a second ticket.

Rules: relax a rule, then add it back

Maybe exports should respect fine-grained permissions. For the first version, only account admins can export, and the finer permissions come in a later ticket.

The split, with numbers

Here's how the 13 might come out after splitting:

Two things to notice. First, the new tickets add up to 12, plus a spike, which is about the same as the original 13. Splitting doesn't make work disappear, and sometimes the pieces add up to more than the original. That's fine: it usually means the split surfaced work the big estimate missed.

Second, the first ticket is useful on its own. If the sprint goes badly and only the 3 ships, customers can still export something. That's what you lose when an 8 or a 13 slips whole.

When a ticket won't split

Sometimes you look hard and there's no clean slice. Lawrence and Green's guide has a meta-pattern for this: find the core complexity, and reduce the variations through it. Build the hardest part for the simplest case first, then add the variations.

If that still doesn't work, there are two honest options:

1. Spike first. If the ticket won't split because nobody understands it yet, the spike is the split.
2. Keep it whole, on purpose. Some work really is one indivisible piece. Accept the 8, start it early in the sprint, and say out loud that it's the riskiest ticket in the plan.

What you shouldn't do is accept the 8 by default because splitting felt like effort.

Splitting in an async session

In a live meeting, a team splits a ticket on the spot. When the team estimates asynchronously, it's easier to make splitting a standing rule. Any ticket that comes in at 8 or more goes back for splitting before it's accepted.

In Async Pointing Poker, the Scrum Master can do this without starting over:

1. Split the ticket in JIRA, into slices as above.
2. Delete the original ticket from the session.
3. Add the new tickets to the session. The team estimates them like any others.

The rest of the session carries on, so the split costs the team one short round of votes, not another meeting. The asynchronous sprint planning guide covers the rest of the workflow.

The short version

• Treat an 8 (or a quarter of your sprint) as a prompt to split, not a final answer.
• Split into slices a user could use, not layers or roles.
• Look for the split with SPIDR: spikes, paths, interfaces, data, rules.
• The pieces won't add up to less than the original. The gain is that each one can ship on its own.
• If it truly won't split, keep it whole on purpose and start it early.

Sources

1. ↩Richard Lawrence and Peter Green, “The Humanizing Work Guide to Splitting User Stories” — 6 to 10 stories per sprint; splitting patterns and the meta-pattern
2. ↩Bill Wake, “INVEST in Good Stories, and SMART Tasks” (2003)
3. ↩Mike Cohn, “SPIDR: Five Simple but Powerful Ways to Split User Stories”