---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?"
---## 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
1. **Pre-Split Validation:** Check if story satisfies 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
**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: 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:**
1. **Yes, can identify simplest core** → "Describe the simplest version + what variations to defer"
2. **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:**
1. **Yes, can defer optimization** → "What's the functional version + what's the optimization?"
2. **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:**
1. **Technical feasibility** — "Can we build this with our stack?"
2. **Approach uncertainty** — "Multiple ways to solve it, unclear which is best"
3. **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:**
1. **Identify core complexity** — What makes this epic hard?
2. **List variations** — What are all the different ways/cases/rules?
3. **Reduce to one complete slice** — Pick the simplest variation that still delivers end-to-end value
4. **Make other variations separate stories**
---
### Cynefin Domain Considerations
**Strategy shifts based on complexity domain:**
**Agent asks:**
"How much uncertainty surrounds this epic?"
**Options:**
1. **Low uncertainty (Obvious/Complicated domain)** — "We know what to build; it's just engineering work"
→ Find all stories, prioritize by value/risk
2. **High uncertainty (Complex domain)** — "We're not sure what customers want or what will work"
