epic-breakdown-advisor
Epic-breakdown-advisor guides product managers through Richard Lawrence's Humanizing Work methodology to split large epics into vertical-slice user stories using nine sequential patterns: workflow steps, operations, business rules, data variations, entry methods, major effort, simple/complex versions, performance deferral, and investigation spikes. Use when a backlog item is too large to estimate, sequence, or deliver safely, and splitting would reveal low-value work to eliminate.
git clone --depth 1 https://github.com/deanpeters/Product-Manager-Skills /tmp/epic-breakdown-advisor && cp -r /tmp/epic-breakdown-advisor/skills/epic-breakdown-advisor ~/.claude/skills/epic-breakdown-advisorSKILL.md
## 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 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 the core complexity 2. List all variations 3. Reduce variations to **one complete slice** 4. Make other variations separate stories ### Why This Works - **Prevents arbitrary splitting:** Methodical checklist prevents guessing - **Preserves user value:** Every story delivers observable value - **Reveals waste:** Good splits expose low-value work you can deprioritize - **Repeatable:** Apply to any epic consistently --- ### Facilitation Source of Truth Use [`workshop-facilitation`](../workshop-facilitation/SKILL.md) as the default interaction protocol for this skill. It defines: - session heads-up + entry mode (Guided, Context dump, Best guess) - one-question turns with plain-language prompts - progress labels (for example, Context Qx/8 and Scoring Qx/5) - interruption handling and pause/resume behavior - numbered recommendations at decision points - quick-select numbered response options for regular questions (include `Other (specify)` when useful) This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic. ## Application ### Step 0: Provide Epic Context **Agent asks:** Please share your epic: - Epic title/ID - Description or hypothesis - Acceptance criteria (especially multiple "When/Then" pairs) - Target persona - Rough estimate **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 insigh
Evaluate acquisition channels using unit economics, customer quality, and scalability. Use when deciding whether to scale, test, or kill a growth channel.
Design multi-agent AI workflows with clear boundaries, handoffs, and monitoring. Use when a complex PM task should run as parallel specialized agents instead of one linear process.
Assess whether your product work is AI-first or AI-shaped. Use when evaluating AI maturity and choosing the next team capability to build.
Understand the PM-to-Director transition through altitude and horizon thinking. Use when diagnosing scope, time-horizon, or leadership-level gaps.
Map evidence-backed growth options across the Ansoff Matrix with risk-rated sequencing. Use when the question is where the next tranche of growth comes from, and at what risk.
The protocol behind every investigation skill. Use when AI research must proceed without you: search-plan gate, Fact/Inference/Assumption labels, confidence stacking, diffable outputs.
Research and draft a competitive battle card from public evidence — every claim labeled and sourced. Use when a rep needs a field-action card, not a research report.
Diagnose SaaS business health across growth, retention, efficiency, and capital. Use when preparing a business review or prioritizing urgent fixes.