Splitting by acceptance criteria

If a story has more than five acceptance criteria, the criteria are the split. The AC list is a backlog wearing a checklist hat.

Acceptance criteria exist to describe a story. They aren't supposed to be the story. When the list gets long — six, eight, ten bullets — the team has already done the splitting work without noticing. Each AC is a thin slice the team could ship, demo, and walk away from. Treating the list as a checklist for "the story" forces the team to commit to all of them at once, which is the worst combination of size and risk you can hand someone in a sprint.

The rule of five

A story with five or fewer acceptance criteria is almost always sprintable. A story with more than five is almost always two stories at minimum, often more. The boundary isn't sacred — six bullets that are obviously small is fine; four bullets where one is "and search works" is almost certainly hiding a sub-story. Use the count as a tripwire, then read the bullets to see what's underneath.

How to split

Take each AC and ask the same question you'd ask of any user story: would the team ship this on its own? Would the user benefit from it on its own? Could it be demoed? The bullets that survive that question are stories. The bullets that fail it usually belong to one of the surviving stories — they're not standalone work, they're scope on a story you've already separated.

Where the technique fails is on tightly coupled criteria — "the form validates input AND saves to the database AND shows a confirmation." Those three look like splittable ACs but the user gets nothing if any one of them ships alone. That's not splittable by AC; it's a single small story, and the bullets are just the team being thorough.

What gets pushed back to refinement

Sometimes the AC count is high because refinement didn't happen. The PM wrote eight bullets to be exhaustive, not because each represents an independently shippable thing. The team can spot this in 30 seconds — half the ACs are about a single user-facing change with different edge cases. That's not a splitting problem; it's a writing problem. Push it back to the PM with "this is one story; the eight bullets are acceptance criteria, not scope."

The other failure mode: someone uses "split by AC" to dodge the harder question — what actually delivers value? Splitting along a flow ("set up auth", "build the form", "wire the database") is not splitting by AC; it's horizontal slicing with AC-shaped labels on top. If the resulting stories don't each ship something the user can see, you split wrong.

Count the ACs. If it's over five, the bullets are the split. Stop voting and start splitting.

Adjacent: definition of ready — the count check belongs in the readiness gate; SPIDR splitting for the other axes when AC-based splitting doesn't fit; can't estimate this story for when a long AC list shows up as vote-spread instead.