메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Research a company, industry, or competitor set using web search and seven analytical lenses. Use when you need structured intel that feeds downstream PM skills.
Identify what to measure, test, or track to de-risk a product or AI idea. Use when stress-testing an idea across internal (DUFV) and external (PESTEL) dimensions.
Plan engagement for a specific stakeholder. Use when preparing an outreach, navigating resistance, or aligning a critical relationship before a key milestone.
Map every stakeholder before engaging anyone. Use when launching an initiative, scoping discovery, or building an engagement plan from scratch.
Prioritize stakeholders using two complementary grids. Use when setting engagement strategy and surfacing whose voice needs elevating after stakeholder identification.
Identify which organic growth path to pursue — new segments, geographies, channels, or products. Use when diagnosing where a growth constraint lives and which McKinsey growth level to act on next.
| name | epic-breakdown-advisor |
| 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?"] |
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