Break a large story or epic into smaller deliverable stories using proven split patterns. Use when backlog items are too big for estimation, sequencing, or independent release.
user-story-splitting breaks a large user story, epic, or feature into smaller, independently deliverable stories using proven split patterns. It is used when backlog items are too big for estimation, sequencing, or independent release, with the goal of making work more manageable, reducing risk, enabling faster feedback cycles, and maintaining flow in agile development. The skill frames this as strategic decomposition that preserves user value, not arbitrary slicing, and applies to any work too large to complete in a single sprint.
The method is based on Richard Lawrence and Peter Green's Humanizing Work Guide to Splitting User Stories, which provides eight systematic patterns worked through in order until one applies: Workflow steps, Business rule variations, Data variations, Acceptance criteria complexity (multiple When or Then statements, noted as the most common indicator), Major effort, External dependencies, DevOps steps, and Tiny Acts of Discovery (TADs) for unpacking unknowns when nothing else fits. The skill takes the story or epic as input (works best with the story pasted as written, plus why it is too big and the team's sizing ceiling; anything supplied inline counts as already-answered context). It applies the splitting logic step by step, using template.md for the full fill-in structure and output format, and includes worked examples for each pattern such as splitting sign-up/verify/onboarding into workflow steps or discount tiers into business rule variations.
The skill targets product managers and agile teams and is explicit about anti-patterns: it is not horizontal slicing into front-end and back-end stories, not task decomposition (stories are not tasks like set up database or write API), and not arbitrary chopping into meaningless fragments. It also lists when not to use it, such as when a story is already small and well-scoped, when splitting would create delivery-slowing dependencies, or when the item is a technical task better handled by engineering task breakdown. Documented in SKILL.md with a template.md and a sample example, it references companion user-story and epic-hypothesis skills for formatting inputs.
Workflow steps, Business rule variations, Data variations, Acceptance criteria complexity, Major effort, External dependencies, DevOps steps, and Tiny Acts of Discovery (TADs). They are worked through in order, stopping at the first that applies; multiple When/Then pairs in acceptance criteria are noted as the most common indicator.
When a story is too large for a single sprint, when acceptance criteria have multiple When or Then statements, when an epic needs breaking into deliverable increments, when the team can't agree on story size, or when a story bundles multiple personas or workflows.
When a story is already small and well-scoped (avoid over-splitting), when splitting would create dependencies that slow delivery, or when the item is a technical task better handled by engineering task breakdown.
Not horizontal slicing into separate front-end and back-end stories, not task decomposition (stories are not tasks like set up database or write API), and not arbitrary chopping into meaningless fragments. Each split story should still deliver user value.
It works best with the too-big story pasted as written, plus why it's too big and the team's sizing ceiling; inline arguments count as already-provided context. It is based on Richard Lawrence and Peter Green's Humanizing Work Guide to Splitting User Stories, and uses template.md for the fill-in output structure.
Quick Setup:
.claude/skills/Repository
deanpeters/product-manager-skills