Guide product managers through breaking down epics into user stories using Richard Lawrence's complete Humanizing Work methodology—a systematic, flowchart-driven approach that applies 9 splitting patterns sequentially. Use this to identify which pattern applies, split while preserving user value, and evaluate splits based on what they reveal about low-value work you can eliminate. This ensures vertical slicing (end-to-end value) rather than horizontal slicing (technical layers).
This is not arbitrary slicing—it's a proven, methodical process that starts with validation, walks through patterns in order, and evaluates results strategically.
A user story is "a description of a change in system behavior from the perspective of a user." Splitting must maintain vertical slices—work that touches multiple architectural layers and delivers observable user value—not horizontal slices addressing single components (e.g., "front-end story" + "back-end story").
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
Agent asks:
Please share your epic:
You can paste from Jira, Linear, or describe briefly.
Before splitting, verify your story satisfies INVEST criteria (except "Small"):
Agent asks questions sequentially:
1. Independent? "Can this story be prioritized and developed without hard technical dependencies on other stories?"
Options:
2. Negotiable? "Does this story leave room for the team to discover implementation details collaboratively, rather than prescribing exact solutions?"
Options:
3. Valuable? "Does this story deliver observable value to a user? (If not, combine it with related work rather than splitting.)"
Options:
⚠️ Critical Check: If story fails "Valuable," STOP. Don't split. Instead, combine with other work to create a meaningful increment.
4. Estimable? "Can your team size this story relatively (even if roughly)?"
Options:
5. Testable? "Does this story have concrete acceptance criteria that QA can verify?"
Options:
If story passes all checks → Proceed to Step 2 (Splitting Patterns) If story fails any check → Fix the issue before splitting
Work through patterns in order. For each pattern, ask "Does this apply?"
Key insight: Split into thin end-to-end slices, not step-by-step. Start with a simple case covering the full workflow, then add intermediate steps as separate stories.
Agent asks: "Does your epic involve a multi-step workflow where you could deliver a simple case first, then add intermediate steps later?"
Example:
Each story delivers full workflow, just with increasing sophistication.
Options:
If YES: Agent generates thin end-to-end slice splits.
Key insight: The word "manage" signals multiple operations. Split into Create, Read, Update, Delete.
Agent asks: "Does your epic use words like 'manage,' 'handle,' or 'maintain'? If so, it likely bundles multiple operations (CRUD)."
Example:
Options:
If YES: Agent generates one story per operation.
Key insight: When identical functionality operates under different rules, each rule becomes its own story.
Agent asks: "Does your epic have different business rules for different scenarios (user types, regions, tiers, conditions)?"
Example:
Options:
If YES: Agent generates one story per rule variation.
Key insight: Complexity from handling different data types or structures. Add variations just-in-time as needed.
Agent asks: "Does your epic handle different data types, formats, or structures (e.g., file types, geographic levels, user attributes)?"
Example:
Options:
If YES: Agent generates one story per data variation (deliver simplest first).
Key insight: UI complexity independent of core functionality. Build simplest interface first, then add sophisticated UI as follow-ups.
Agent asks: "Does your epic include fancy UI elements (date pickers, autocomplete, drag-and-drop) that aren't essential to core functionality?"
Example:
Options:
If YES: Agent generates Story 1 = basic input, Story 2+ = UI enhancements.
Key insight: When initial implementation carries most complexity, with additions being trivial. Frame as "implement one + add remaining."
Agent asks: "Does your epic involve building infrastructure where the first implementation is hard, but adding more is easy?"
Example:
⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.
Options:
If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.
Key insight: Identify story's core by asking "What's the simplest version?" Extract variations into separate stories.
Agent asks: "What's the simplest version of this epic that still delivers value? Can you strip away complexity and add it back later?"
Example:
Options:
If YES: Agent generates Story 1 = simplest core, Story 2+ = variations.
Key insight: Split "make it work" from "make it fast." Non-functional requirements (performance, security, scalability) can follow functional delivery.
Agent asks: "Can you deliver functional value first, then optimize performance/security/scalability later?"
Example:
Options:
If YES: Agent generates Story 1 = functional, Story 2 = optimize.
Key insight: Last resort when uncertainty prevents splitting. Time-box investigation to answer specific questions, then split implementation story with better understanding.
Agent says: "None of patterns 1-8 apply, which suggests high uncertainty. Before splitting, run a spike to reduce uncertainty."
A spike is a time-boxed investigation (not a story), answering questions like:
Agent asks: "What's the biggest unknown preventing you from splitting this epic?"
Options:
Agent recommends: → "Run a 1-2 day spike to answer [question]. After the spike, come back and we'll split the epic with better understanding."
⚠️ Spikes produce learning, not shippable code. After the spike, restart at Pattern 1.
After splitting, evaluate using these criteria:
Agent asks:
1. Does this split reveal low-value work you can deprioritize or eliminate?
2. Does this split produce more equally-sized stories?
If split doesn't satisfy either criterion, try a different pattern.
Across all patterns, follow this sequence:
Strategy shifts based on complexity domain:
Agent asks: "How much uncertainty surrounds this epic?"
Options:
Low uncertainty (Obvious/Complicated domain) — "We know what to build; it's just engineering work" → Find all stories, prioritize by value/risk
High uncertainty (Complex domain) — "We're not sure what customers want or what will work" → Identify 1-2 learning stories; avoid exhaustive enumeration (work itself teaches what matters)
Chaos — "Everything is on fire; priorities shift daily" → Defer splitting until stability emerges; focus on stabilization first
# Epic Breakdown Plan
**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]
---
## Story Breakdown
### Story 1: [Title] (Simplest Complete Slice)
**Summary:** [User-value-focused title]
**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]
**Acceptance Criteria:**
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]
**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]
---
### Story 2: [Title] (First Variation)
[Repeat...]
---
### Story 3: [Title] (Second Variation)
[Repeat...]
---
## Split Evaluation
✅ **Does this split reveal low-value work?**
- [Analysis: Which stories could be deprioritized/eliminated?]
✅ **Does this split produce equal-sized stories?**
- [Analysis: Are stories roughly equal in effort?]
---
## INVEST Validation (Each Story)
✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each
---
## Next Steps
1. **Review with team:** Do PM, design, engineering agree?
2. **Check for further splitting:** Are any stories still >5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.
---
**If stories are still too large, re-apply patterns starting at Pattern 1.**
Epic: "Publish blog post (requires editorial review, legal approval, staging)"
Pre-Split Validation: ✅ Passes INVEST
Pattern 1: "Does this have workflow steps?" → YES ✅
❌ Wrong Split (Step-by-Step):
✅ Right Split (Thin End-to-End):
Why this works: Each story delivers full workflow, just with increasing sophistication.
Epic: "Manage user profiles"
Pattern 2: "Does this say 'manage'?" → YES ✅ (signals CRUD)
Split:
Split Evaluation:
Epic: "Flight search with max stops, nearby airports, flexible dates"
Pattern 7: "What's the simplest version?" → Basic search ✅
Split:
Split Evaluation:
Epic: "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"
First Pass - Pattern 1 (Workflow): YES ✅
Check Story 2 ("Apply discount"): Still 4 days → Too large, re-split
Second Pass on Story 2 - Pattern 3 (Business Rules): YES ✅
Check Story 3 ("Complete payment"): Still 5 days → Too large, re-split
Third Pass on Story 3 - Pattern 6 (Major Effort): YES ✅
Final Breakdown: 6 stories, all 1-2 days each
Symptom: Jump straight to splitting without checking INVEST
Consequence: Split a story that shouldn't be split (e.g., not Valuable = technical task)
Fix: Always run Step 1 (INVEST check) before Step 2 (splitting patterns)
Symptom: Story 1 = "Editorial review," Story 2 = "Legal approval"
Consequence: Stories don't deliver end-to-end value
Fix: Each story should cover full workflow (thin end-to-end slice), just with increasing sophistication
Symptom: "Story 1: Build API. Story 2: Build UI."
Consequence: Neither story delivers user value
Fix: Vertical slicing—each story includes front-end + back-end to deliver observable user behavior
Symptom: "We'll split by workflow even though there's no sequence"
Consequence: Arbitrary, meaningless split
Fix: If pattern doesn't apply, say NO and continue to next pattern
Symptom: Split epic into 3 stories, but each is still 5+ days
Consequence: Stories too large for sprint
Fix: Restart at Pattern 1 for each large story until all are 1-5 days
Symptom: Split but don't evaluate if it reveals low-value work
Consequence: Miss opportunity to eliminate waste
Fix: After splitting, ask: "Does this reveal work we can kill or defer?"
Humanizing Work recommendation: Teams reach fluency in 2.5-3 hours across multiple practice sessions.
Practice approach:
Don't skip practice work. Skill develops through analyzing past deliverables, not just refining future work.
user-story-splitting.md — The 9 patterns in detailuser-story.md — Format for writing storiesepic-hypothesis.md — Original epic formatSkill type: Interactive
Suggested filename: epic-breakdown-advisor.md
Suggested placement: /skills/interactive/
Dependencies: Uses user-story-splitting.md, user-story.md, epic-hypothesis.md