Download skills/epic-breakdown-advisor/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does epic-breakdown-advisor live?
The publisher keeps it at https://github.com/deanpeters/Product-Manager-Skills.
Which agents can use epic-breakdown-advisor?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
Break down epics into user stories with Humanizing Work split patterns. Use when a backlog item is too large to estimate, sequence, or deliver safely.
name: epic-breakdown-advisor
argument-hint: "[epic to split]"
description: Break down epics into user stories with Humanizing Work split patterns. Use when a backlog item is too large to estimate, sequence, or deliver safely.
intent: >-
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).
type: interactive
best_for:
"Splitting epics into smaller vertical slices"
"Choosing the right story split pattern for a large backlog item"
"Turning vague feature blobs into sprint-sized stories"
scenarios:
"Break this onboarding epic into smaller user stories"
"Help me split a large reporting feature before sprint planning"
"Which story-splitting pattern should I use for this admin workflow epic?"
theme: pm-artifacts
estimated_time: "20-30 min"
Purpose
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.
Input
Works best with: The epic or large story you need to break down — paste it as written in your backlog.
Also useful: Team context (sprint length, estimation ceiling) and what's blocking delivery (too big to estimate, sequence, or release).
Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.
Arriving empty-handed? That works too. The advisor opens by asking for the epic text, then walks the Humanizing Work pattern flowchart against it.
Example invocation:Break this down: 'As a finance admin, I can export any report to Excel, PDF, or CSV with custom date ranges and saved templates.'
Key Concepts
Core Principles: Vertical Slices Preserve Value
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").
The Three-Step Process
Pre-Split Validation: Check if story satisfies INVEST criteria (except "Small")
Apply Splitting Patterns: Work through 9 patterns sequentially until one fits
Evaluate Splits: Choose the split that reveals low-value work or produces equal-sized stories
The 9 Splitting Patterns (In Order)
Workflow Steps — Thin end-to-end slices, not step-by-step
Operations (CRUD) — Create, Read, Update, Delete as separate stories
Business Rule Variations — Different rules = different stories
Data Variations — Different data types/structures
Data Entry Methods — Simple UI first, fancy UI later
Major Effort — "Implement one + add remaining"
Simple/Complex — Core simplest version first, variations later
Defer Performance — "Make it work" before "make it fast"
Break Out a Spike — Time-box investigation when uncertainty blocks splitting
You can paste from Jira, Linear, or describe briefly.
Step 1: Pre-Split Validation (INVEST Check)
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:
Yes — No blocking dependencies
No — Requires other work first (flag this)
2. Negotiable?
"Does this story leave room for the team to discover implementation details collaboratively, rather than prescribing exact solutions?"
Options:
Yes — It's a conversation starter, not a spec
No — It's too prescriptive (may need reframing)
3. Valuable?
"Does this story deliver observable value to a user? (If not, combine it with related work rather than splitting.)"
Options:
Yes — Users see/experience something different
No — It's a technical task (not a user story—don't split, reframe)
⚠️ 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:
Yes — Team can estimate days/points
No — Too much uncertainty (may need spike first)
5. Testable?
"Does this story have concrete acceptance criteria that QA can verify?"
Options:
Yes — Clear pass/fail conditions
No — Needs clearer acceptance criteria (refine before splitting)
If story passes all checks → Proceed to Step 2 (Splitting Patterns)If story fails any check → Fix the issue before splitting
Step 2: Apply Splitting Patterns Sequentially
Work through patterns in order. For each pattern, ask "Does this apply?"
Pattern 1: Workflow Steps
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?"
Story 1: Accept Visa payments (build full payment infrastructure)
Story 2: Add Mastercard, Amex, Discover support (trivial additions)
⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.
Options:
Yes, major effort pattern → "What's the first implementation + what are the additions?"
No, no infrastructure work → Continue to Pattern 7
If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.
Pattern 7: Simple/Complex
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:
Original: "Flight search (with max stops, nearby airports, flexible dates)"
Split:
Story 1: Basic flight search (origin, destination, date)
Story 2: Add max stops filter
Story 3: Add nearby airports option
Story 4: Add flexible dates option
Options:
Yes, can identify simplest core → "Describe the simplest version + what variations to defer"
No, it's already simple → Continue to Pattern 8
If YES: Agent generates Story 1 = simplest core, Story 2+ = variations.
Pattern 8: Defer Performance
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:
Original: "Real-time search with <100ms response time"
Split:
Story 1: Search works (functional, no performance guarantee)
Story 2: Optimize search to <100ms (add caching, indexing)
Options:
Yes, can defer optimization → "What's the functional version + what's the optimization?"
No, performance is essential → Continue to Pattern 9
If YES: Agent generates Story 1 = functional, Story 2 = optimize.
Pattern 9: Break Out a Spike
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:
Is this technically feasible?
Which approach performs best?
What does the API actually return?
Agent asks:
"What's the biggest unknown preventing you from splitting this epic?"
Options:
Technical feasibility — "Can we build this with our stack?"
Approach uncertainty — "Multiple ways to solve it, unclear which is best"
External dependency — "Don't know what third-party API provides"
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.
Step 3: Evaluate Split Quality
After splitting, evaluate using these criteria:
Agent asks:
1. Does this split reveal low-value work you can deprioritize or eliminate?
Good splits expose the 80/20 principle: most value concentrates in a small portion of functionality
Example: After splitting "Flight search" into 4 stories, you realize "flexible dates" is rarely used → deprioritize or kill it
2. Does this split produce more equally-sized stories?
Equal-sized stories give Product Owners greater prioritization flexibility
Example: Instead of one 10-day epic, five 2-day stories allow reordering mid-sprint
If split doesn't satisfy either criterion, try a different pattern.
Meta-Pattern Application
Across all patterns, follow this sequence:
Identify core complexity — What makes this epic hard?
List variations — What are all the different ways/cases/rules?
Reduce to one complete slice — Pick the simplest variation that still delivers end-to-end value
Make other variations separate stories
Cynefin Domain Considerations
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
Output: Generate Story Breakdown
# 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.**
Examples
Example 1: Pattern 1 Applied (Workflow Steps - Thin End-to-End)
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):
Editorial review story
Legal approval story
Publish story
→ Problem: Story 1 doesn't deliver value (users see nothing)
✅ Right Split (Thin End-to-End):
Publish post (simple path) — Author uploads, post goes live immediately (no reviews)
Add editorial review — Post now waits for editor approval before going live
Add legal approval — Post waits for legal + editorial before going live
Why this works: Each story delivers full workflow, just with increasing sophistication.
Example 2: Pattern 2 Applied (CRUD Operations)
Epic: "Manage user profiles"
Pattern 2: "Does this say 'manage'?" → YES ✅ (signals CRUD)
Split:
Create user profile
View user profile details
Edit user profile info
Delete user profile
Split Evaluation:
✅ Reveals low-value work: After analysis, "Delete profile" is rarely used → deprioritize
✅ Equal-sized stories: Each 1-2 days
Example 3: Pattern 7 Applied (Simple/Complex)
Epic: "Flight search with max stops, nearby airports, flexible dates"
Pattern 7: "What's the simplest version?" → Basic search ✅
Split:
Basic flight search (origin, destination, date) — Core value
Add max stops filter — Enhancement
Add nearby airports option — Enhancement
Add flexible dates option — Enhancement
Split Evaluation:
✅ Reveals low-value work: User research shows "flexible dates" rarely used → kill or defer
✅ Equal-sized stories: Story 1 = 3 days, others = 1 day each
Example 4: Iterative Splitting (Multiple Patterns)
Epic: "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"
First Pass - Pattern 1 (Workflow): YES ✅
Story 1: Add items to cart
Story 2: Apply discount
Story 3: Complete payment
Check Story 2 ("Apply discount"): Still 4 days → Too large, re-split
Second Pass on Story 2 - Pattern 3 (Business Rules): YES ✅
Story 2a: Apply member discount (10%)
Story 2b: Apply VIP discount (20%)
Story 2c: Apply first-time discount (5%)
Check Story 3 ("Complete payment"): Still 5 days → Too large, re-split
Third Pass on Story 3 - Pattern 6 (Major Effort): YES ✅
Story 3a: Accept Visa payments (build payment infrastructure)
Story 3b: Add Mastercard, Amex support
Final Breakdown: 6 stories, all 1-2 days each
Common Pitfalls
Pitfall 1: Skipping Pre-Split Validation
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)
Download skills/epic-breakdown-advisor/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does epic-breakdown-advisor live?
The publisher keeps it at https://github.com/deanpeters/Product-Manager-Skills.
Which agents can use epic-breakdown-advisor?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.