Paste a too-large user story. Get 8 split patterns — workflow steps, happy/sad, data variation, CRUD, persona, platform, business rules, spike+build — with templates and worked examples.
How big is the current story?
Paste a story or epic above to see split options.
SprintFlint flags oversized tickets at refinement, links split children to parents, and tracks split-rate sprint over sprint.
Start FreeThree signals: the team can't agree on points (every estimate is wildly different), the story has more than ~5 acceptance criteria, or the team feels like splitting would help but isn't sure how. If any two are true, split.
Most stories fit at least one of the eight patterns. If none fit, the story might be a chore, a research task, or a bundle of unrelated work — name it accordingly rather than forcing a split.
Yes. The point of splitting is to ship working increments, not to break work into smaller technical tasks. If a split story can't be demoed, you've split horizontally (frontend/backend) — split vertically instead.
If the story is under 1 point and ships in less than half a day, it's probably overhead-heavy. Bundle it with related small stories. The 1-3 point sweet spot tends to optimise for both forecastability and shipping cadence.
It's only a cop-out if the spike never produces a decision. Timebox the spike (1-3 days), require a written output, and force a split decision at the end. If teams default to "spike everything", that's a refinement problem.
Most user-facing stories are sequences. The first step is almost always shippable on its own (even if behind a flag), and each step proves part of the path. Workflow-steps is the default — try the others when it doesn't fit.
INVEST checklist (story quality), Acceptance criteria formats, Story-point estimation, Definition of Done generator.