User Story Splitting
Split oversized backlog epics into sprint-sized user stories your agent can estimate, sequence, and ship independently.
Overview
User-story-splitting is an agent skill most often used in Validate (also Build, Ship) that breaks large epics into smaller, value-preserving user stories using eight systematic agile splitting patterns.
Install
npx skills add https://github.com/deanpeters/product-manager-skills --skill user-story-splittingWhat is this skill?
- Applies Richard Lawrence and Peter Green’s Humanizing Work 8-pattern story-splitting framework
- Splits on workflow steps, business rules, data variations, operations, interfaces, and deferring complexity
- Preserves user value per slice instead of arbitrary technical-only cuts
- Reduces estimation risk and keeps agile flow when items are too big for one sprint
- Strategic decomposition for user stories, epics, and any work chunk that blocks sequencing
- 8 systematic story-splitting patterns from the Humanizing Work guide
Adoption & trust: 1.3k installs on skills.sh; 5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a fat epic or user story that no one can estimate, sequence, or ship in one iteration without hidden dependencies.
Who is it for?
Solo or indie builders grooming a backlog before sprint planning, agent task lists, or incremental releases from a single oversized feature.
Skip if: Teams that already have sprint-sized, independently testable stories with clear acceptance criteria and no estimation or sequencing pain.
When should I use this skill?
Backlog items are too big for estimation, sequencing, or independent release.
What do I get? / Deliverables
You get a set of smaller, independently deliverable stories aligned to proven split patterns so estimation, sprint planning, and incremental release can proceed with less risk.
- Set of smaller user stories with preserved user value
- Rationale tied to one or more of the eight split patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because splitting is the core scoping move before you commit build capacity—turning vague epics into releasable slices. Scope subphase is where backlog items get right-sized for estimation and independent release, which is exactly when this skill should fire.
Where it fits
Split a “full checkout redesign” epic into releasable stories before committing a two-month build.
Groom agent implementation queues so each story maps to one vertical slice of user value.
Sequence launch-ready increments when marketing wants early partial value instead of one big bang release.
How it compares
Use structured splitting patterns instead of ad-hoc “just break it into tasks” chat that drops user value or creates cross-sprint glue work.
Common Questions / FAQ
Who is user-story-splitting for?
It is for solo and indie builders (and small PM-led teams) who run agile-style backlogs and need agent help decomposing epics without losing user-centric outcomes.
When should I use user-story-splitting?
Use it during Validate when scoping a feature, during Build when grooming PM backlog for implementation, and during Ship when sequencing work for independent releases—whenever items are too big to estimate or ship alone.
Is user-story-splitting safe to install?
It is documentation-only procedural guidance with no shell or network access by itself; review the Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - User Story Splitting
## Purpose 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. ## Key Concepts ### The Story Splitting Framework Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work: 1. **Workflow steps:** Split along sequential steps in a user's journey 2. **Business rule variations:** Split by different rule scenarios (permissions, calculations, etc.) 3. **Data variations:** Split by different data types or inputs 4. **Acceptance criteria complexity:** Split when multiple "When" or "Then" statements exist 5. **Major effort:** Split by technical milestones or implementation phases 6. **External dependencies:** Split along dependency boundaries (APIs, third parties, etc.) 7. **DevOps steps:** Split by deployment or infrastructure requirements 8. **Tiny Acts of Discovery (TADs):** When none of the above apply, use small experiments to unpack unknowns ### Why Split Stories? - **Faster feedback:** Smaller stories ship sooner, allowing earlier validation - **Reduced risk:** Less to build = less that can go wrong - **Better estimation:** Small stories are easier to estimate accurately - **Maintain flow:** Keeps work moving through the sprint without bottlenecks - **Testability:** Smaller scope = easier to write and run tests ### Anti-Patterns (What This Is NOT) - **Not horizontal slicing:** Don't split into "front-end story" and "back-end story" (each story should deliver user value) - **Not task decomposition:** Stories aren't tasks ("Set up database," "Write API") - **Not arbitrary chopping:** Don't split "Add user management" into "Add user" and "Management" (meaningless) ### When to Use This - Story is too large for a single sprint - Multiple "When" or "Then" statements in acceptance criteria - Epic needs to be broken down into deliverable increments - Team can't reach consensus on story size or scope - Story has multiple personas or workflows bundled together ### When NOT to Use This - Story is already small and well-scoped (don't over-split) - Splitting would create dependencies that slow delivery - The story is a technical task (use engineering task breakdown instead) --- ## Application ### Step 1: Identify the Original Story 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`). ```markdown ### Original Story: [Story formatted with use case and acceptance criteria] ``` --- ### Step 2: Apply the Splitting Logic 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. #### Pattern 1: Workflow Steps **Ask:** Does this story contain multiple sequential steps? **Example:** - Original: "As a user, I want to sign up, verify my email, and complete onboarding" - Split: 1. "As a user,