/epic-breakdown-advisor

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?"

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 (re