Product ManagementIntermediate
Epic Breakdown Advisor (Humanizing Work)
Break epics into user stories using the Humanizing Work methodology — INVEST validation, 9 splitting patterns applied sequentially, and evaluation criteria that expose low-value work.
#user-stories#backlog-refinement#sprint-planning#humanizing-work#vertical-slicing#invest
Your epic is "Manage user profiles," estimated at 3 weeks, and the team is arguing about whether to split it by screen, by layer, or by user type. The Humanizing Work methodology answers that: INVEST first, then walk 9 patterns in order, then evaluate the split for whether it reveals work you can kill. The word "manage" alone tells you the pattern.
Who it's for: PMs splitting epics before sprint planning, scrum masters coaching story-splitting, tech leads who keep getting backlog items sized as 8-day monsters, agile coaches teaching vertical slicing, PM/eng pairs in backlog refinement
Example
"Help me split this onboarding epic — it's estimated at 12 days and we need to sprint it" → INVEST check + apply Pattern 1 (workflow) with thin end-to-end slices + each story covers full flow with increasing sophistication + split evaluation flags low-usage steps to deprioritize + final 4 stories at 2-3 days each
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Epic Breakdown Advisor
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. Each split preserves **vertical slices** (end-to-end value) rather than horizontal slices (technical layers).
This is not arbitrary slicing—it's a proven, methodical process: validate → apply patterns in order → evaluate results strategically.
## Three-Step Process
1. **Pre-Split Validation:** Check INVEST criteria (except "Small")
2. **Apply Splitting Patterns:** Work through 9 patterns sequentially until one fits
3. **Evaluate Splits:** Choose the split that reveals low-value work or produces equal-sized stories
## The 9 Splitting Patterns (In Order)
1. **Workflow Steps** — Thin end-to-end slices, not step-by-step
2. **Operations (CRUD)** — Create, Read, Update, Delete as separate stories
3. **Business Rule Variations** — Different rules = different stories
4. **Data Variations** — Different data types/structures
5. **Data Entry Methods** — Simple UI first, fancy UI later
6. **Major Effort** — "Implement one + add remaining"
7. **Simple/Complex** — Core simplest version first, variations later
8. **Defer Performance** — "Make it work" before "make it fast"
9. **Break Out a Spike** — Time-box investigation when uncertainty blocks splitting
## Meta-Pattern (Applies Across All Patterns)
1. Identify core complexity
2. List all variations
3. Reduce variations to **one complete slice**
4. Make other variations separate stories
## Application
### Step 0: Provide Epic Context
- Epic title/ID, description or hypothesis
- Acceptance criteria (especially multiple When/Then pairs)
- Target persona
- Rough estimate
### Step 1: Pre-Split Validation (INVEST Check)
1. **Independent?** Can it be prioritized/developed without blocking dependencies?
2. **Negotiable?** Room for collaborative discovery (not prescriptive spec)?
3. **Valuable?** Delivers observable value to a user? **If NO: STOP. Don't split — reframe.**
4. **Estimable?** Team can size relatively?
5. **Testable?** Concrete acceptance criteria?
**If any fail → fix before splitting.**
### Step 2: Apply Splitting Patterns Sequentially
#### Pattern 1: Workflow Steps (Thin End-to-End)
Split into **thin end-to-end slices**, not step-by-step.
**❌ Wrong (step-by-step):** Editorial review → Legal approval → Publish
**✅ Right (thin end-to-end):**
- Story 1: Publish (simple path: author uploads, goes live immediately)
- Story 2: Add editorial review step
- Story 3: Add legal approval step
Each story delivers **full workflow**, just with increasing sophistication.
#### Pattern 2: Operations (CRUD)
The word "manage" signals multiple operations.
**Original:** "Manage user accounts"
**Split:** Create account, View details, Edit info, Delete account
#### Pattern 3: Business Rule Variations
Identical functionality under different rules → one story per rule.
**Original:** "Flight search with flexible dates (date range, weekends, offsets)"
**Split:** Search by date range / Search by weekends / Search by offsets
#### Pattern 4: Data Variations
Complexity from different data types → just-in-time additions.
**Original:** "Geographic search (counties, cities/towns, custom areas)"
**Split:** By county → by city/town → by custom area
#### Pattern 5: Data Entry Methods
UI complexity independent of core functionality.
**Original:** "Search with calendar date picker"
**Split:** Basic text input → visual calendar picker
#### Pattern 6: Major Effort
First implementation carries most complexity; additions trivial.
**Original:** "Accept credit cards (Visa, MC, Amex, Discover)"
**Split:** Accept Visa (build full infra) → add MC/Amex/Discover (trivial)
#### Pattern 7: Simple/Complex
Strip complexity to core; add back as variations.
**Original:** "Flight search with stops, nearby airports, flexible dates"
**Split:** Basic search → max stops → nearby airports → flexible dates
#### Pattern 8: Defer Performance
"Make it work" before "make it fast."
**Original:** "Real-time search <100ms"
**Split:** Search works (functional) → optimize to <100ms
#### Pattern 9: Break Out a Spike
Last resort: high uncertainty prevents splitting. Run 1-2 day time-boxed investigation. **Spikes produce learning, not shippable code.** After spike, restart at Pattern 1.
### Step 3: Evaluate Split Quality
1. **Does this split reveal low-value work to deprioritize or eliminate?** (Good splits expose 80/20)
2. **Does this split produce more equally-sized stories?** (Equal sizes = prioritization flexibility)
**If neither → try a different pattern.**
### Cynefin Domain Considerations
- **Low uncertainty (Obvious/Complicated):** Find all stories, prioritize by value/risk
- **High uncertainty (Complex):** Identify 1-2 **learning stories**; avoid exhaustive enumeration
- **Chaos:** **Defer splitting** until stability emerges; stabilize first
## Output Template
```markdown
# Epic Breakdown Plan
**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]
## Story Breakdown
### Story 1: [Title] (Simplest Complete Slice)
**Use Case:** As a [persona], I want to [action], so that [outcome]
**Acceptance Criteria:** Given/When/Then
**Why This First:** [Core value]
**Estimated Effort:** [Days/points]
### Story 2: [Title] (First Variation)
[Repeat...]
## Split Evaluation
- Reveals low-value work? [Analysis]
- Equal-sized stories? [Analysis]
## INVEST Validation (Each Story)
- Independent / Negotiable / Valuable / Estimable / Small / Testable
```
## Common Pitfalls
1. **Skipping pre-split validation** — Splits non-Valuable stories → technical tasks, not user stories. Fix: always run INVEST first.
2. **Step-by-step workflow splitting (Pattern 1 wrong)** — Individual steps don't deliver value. Fix: thin end-to-end slices.
3. **Horizontal slicing** — "Build API" + "Build UI" → neither delivers value alone. Fix: vertical slices through layers.
4. **Forcing a pattern** — Arbitrary splits by workflow when there's no sequence. Fix: if pattern doesn't apply, continue to next.
5. **Not re-splitting large stories** — 3 stories × 5 days each still too large. Fix: restart Pattern 1 for each.
6. **Ignoring split evaluation** — Miss waste-elimination opportunities. Fix: ask "what can we kill or defer?"
## Practice Recommendation
Humanizing Work: teams reach fluency in **2.5–3 hours** across multiple sessions.
1. Analyze recently completed features (hindsight makes patterns obvious)
2. Walk completed work through the flowchart
3. Find multiple split approaches per feature
4. Build shared vocabulary of domain examples
## References
- Richard Lawrence & Peter Green, *The Humanizing Work Guide to Splitting User Stories*
- Bill Wake, *INVEST in Good Stories* (2003)
- https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/
README.md
What This Does
Walks through Richard Lawrence's Humanizing Work story-splitting methodology: INVEST validation → apply 9 splitting patterns sequentially → evaluate splits for waste-elimination and size equality. Produces vertical slices (end-to-end value), not horizontal slices (technical layers).
Not arbitrary slicing. A systematic, flowchart-driven process.
Quick Start
mkdir -p ~/Documents/EpicBreakdown
mv ~/Downloads/CLAUDE.md ~/Documents/EpicBreakdown/
cd ~/Documents/EpicBreakdown
claude
Paste your epic (title, description, acceptance criteria, persona, rough estimate). Claude validates INVEST, applies patterns in order, and delivers the breakdown.
The 9 Patterns (Applied in Order)
| # | Pattern | Signal | Example |
|---|---|---|---|
| 1 | Workflow Steps | Multi-step process | Thin end-to-end slices, not step-by-step |
| 2 | Operations (CRUD) | Word "manage" | Create/Read/Update/Delete stories |
| 3 | Business Rule Variations | Different rules per segment | One story per rule |
| 4 | Data Variations | Different data types | Just-in-time additions |
| 5 | Data Entry Methods | Fancy UI | Simple input → sophisticated UI later |
| 6 | Major Effort | Infrastructure build | First implementation + trivial additions |
| 7 | Simple/Complex | Has optional complexity | Core simplest + variations |
| 8 | Defer Performance | Non-functional requirements | Make it work → make it fast |
| 9 | Break Out a Spike | High uncertainty | Time-box investigation, then restart |
Pre-Split INVEST Check
Before splitting, verify (except "Small"):
- Independent — No blocking dependencies
- Negotiable — Collaborative discovery, not prescriptive spec
- Valuable — Observable user value (if NO: STOP, reframe)
- Estimable — Team can size
- Testable — Concrete acceptance criteria
Split Evaluation (Step 3)
- Does this reveal low-value work to kill or defer? Good splits expose the 80/20.
- Are stories equally sized? Equal sizes give the PO prioritization flexibility.
If neither → try a different pattern.
Tips & Best Practices
- Vertical slices always. "Build API" + "Build UI" fails — neither delivers value. Each story touches all layers.
- Pattern 1 done right = thin end-to-end. Story 1 is full workflow with simplest path; Stories 2+ add sophistication.
- The word "manage" is diagnostic. It signals CRUD — split by operation.
- After splitting, re-check story sizes. If any > 5 days, restart Pattern 1 for that story.
- Cynefin matters. Complex domain = 1–2 learning stories, not exhaustive enumeration.
Common Pitfalls
- Skipping INVEST validation and splitting technical tasks as if they were stories
- Step-by-step splits that don't deliver end-to-end value
- Horizontal (layer-based) slicing that masquerades as vertical
- Forcing a pattern that doesn't fit instead of moving to the next
- Not re-splitting stories that are still too large after one pass