Help us improve
Share bugs, ideas, or general feedback.
Breaks large stories or epics into smaller deliverable stories using 8 systematic splitting patterns. Use when backlog items are too big for estimation, sequencing, or independent release.
npx claudepluginhub deanpeters/product-manager-skills --plugin workshop-facilitationHow this skill is triggered — by the user, by Claude, or both
Slash command
/product-manager-skills:user-story-splittingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.
Breaks down epics into user stories using Humanizing Work's 9 splitting patterns. Use when a backlog item is too large to estimate, sequence, or deliver safely.
Detects overly large user stories and applies heuristic splitting to decompose them into small, safe, valuable increments. Works after validate-stories, as last step before prioritization/execution.
Breaks PRDs or feature descriptions into implementable user stories with acceptance criteria, priorities, and notes. Use for sprint planning or engineering handoff.
Share bugs, ideas, or general feedback.
Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.
This is not arbitrary slicing—it's strategic decomposition that preserves user value while reducing complexity.
Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:
Start with the story/epic/feature that needs splitting. Ensure it's written using the user story format (reference skills/user-story/SKILL.md or skills/epic-hypothesis/SKILL.md).
### Original Story:
[Story formatted with use case and acceptance criteria]
Use template.md for the full fill-in structure and output format.
Work through the 8 splitting patterns in order. Stop when you find one that applies.
Ask: Does this story contain multiple sequential steps?
Example:
Ask: Does this story have different rules for different scenarios?
Example:
Ask: Does this story handle different types of data or inputs?
Example:
Ask: Does this story have multiple "When" or "Then" statements?
Example:
Note: This is the most common indicator that a story needs splitting. If you see multiple "When/Then" pairs, split along those boundaries.
Ask: Does this story require significant technical work that can be delivered incrementally?
Example:
Ask: Does this story depend on multiple external systems or APIs?
Example:
Ask: Does this story require complex deployment, infrastructure, or operational work?
Example:
Ask: If none of the above apply, are there unknowns or assumptions that need unpacking?
Example:
Note: TADs aren't stories—they're experiments. Use them to de-risk and clarify before writing stories.
For each split, write a complete user story using the format from skills/user-story/SKILL.md:
### Split 1 using [Pattern Name]:
#### User Story [ID]:
- **Summary:** [Brief title]
**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]
**Acceptance Criteria:**
- **Scenario:** [Description]
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]
Ask these questions:
If any answer is "no," revise.
See examples/sample.md for full splitting examples.
Mini example excerpt:
### Original Story:
As a team admin, I want to manage team members so that I can control access.
### Suggested Splits (Acceptance Criteria Complexity):
1. Invite new team members
2. Remove team members
3. Update team member roles
Symptom: "Story 1: Build the API. Story 2: Build the UI."
Consequence: Neither story delivers user value independently.
Fix: Split vertically—each story should include front-end + back-end work to deliver a complete user-facing capability.
Symptom: "Story 1: Add button. Story 2: Wire button to API. Story 3: Display result."
Consequence: Creates unnecessary overhead and dependencies.
Fix: Only split when the story is too large. A 2-day story doesn't need splitting.
Symptom: "Story 1: First half of feature. Story 2: Second half of feature."
Consequence: Arbitrary splits that don't map to user value or workflow.
Fix: Use one of the 8 splitting patterns—each split should have a clear rationale.
Symptom: "Story 2 can't start until Story 1 is 100% done, tested, and deployed."
Consequence: No parallelization, slows delivery.
Fix: Split in a way that allows independent development. If dependencies are unavoidable, prioritize Story 1.
Symptom: Split stories have the same "so that" statement.
Consequence: You've split the action but not the outcome—likely a task decomposition, not a story split.
Fix: Ensure each split has a distinct user outcome. If not, reconsider the split pattern.
skills/user-story/SKILL.md — Format for writing the split storiesskills/epic-hypothesis/SKILL.md — Epics often need splitting before becoming storiesskills/jobs-to-be-done/SKILL.md — Helps identify meaningful splits along user jobsprompts/user-story-splitting-prompt-template.md in the https://github.com/deanpeters/product-manager-prompts repo.Skill type: Component
Suggested filename: user-story-splitting.md
Suggested placement: /skills/components/
Dependencies: References skills/user-story/SKILL.md, skills/epic-hypothesis/SKILL.md
Applies to: User stories, epics, and any work that's too large to complete in a single sprint