epic-breakdown-advisor

What this skill does

## 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.

## 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 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:**
- **Original:** "Publish content (requires editorial review, legal approval, staging)"
- **❌ Wrong split (step-by-step):** Story 1 = Editorial review, Story 2 = Legal approval, Story 3 = Publish
- **✅ Right split (thin end-to-end):**
  - Story 1: Publish content (simple path: author uploads, content goes live immediately—no reviews)
  - Story 2: Add editorial review step (now content waits for editor approval before going live)
  - Story 3: Add legal approval step (content waits for legal + editorial before going live)

**Each story delivers full workflow**, just with increasing sophistication.

**Options:**
1. **Yes, multi-step workflow** → "Describe the workflow steps"
2. **No, single step** → Continue to Pattern 2

**If YES:** Agent generates thin end-to-end slice splits.

---

### Pattern 2: Operations (CRUD)

**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:**
- **Original:** "Manage user accounts"
- **Split:**
  - Story 1: Create user account
  - Story 2: View user account details
  - Story 3: Edit user account info
  - Story 4: Delete user account

**Options:**
1. **Yes, contains multiple operations** → "List the operations (Create/Read/Update/Delete/etc.)"
2. **No, single operation** → Continue to Pattern 3

**If YES:** Agent generates one story per operation.

---

### Pattern 3: Business Rule Variations

**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:**
- **Original:** "Flight search with flexible dates (date range, specific weekends, date offsets)"
- **Split:**
  - Story 1: Search by date range (+/- N days)
  - Story 2: Search by specific weekends only
  - Story 3: Search by date offsets (N days before/after)

**Options:**
1. **Yes, different rules** → "Describe the rule variations"
2. **No, same rules for all** → Continue to Pattern 4

**If YES:** Agent generates one story per rule variation.

---

### Pattern 4: Data Variations

**Key insight:** Complexity from handling different data types or structures. Add variations **just-in-time** as needed.

**Agent asks:**
"Does your epic handle different dat