epic-breakdown-advisor
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.
By deanpeters · 2,146 installs
npx skills add deanpeters/product-manager-skills --skill epic-breakdown-advisor
Source repository · Upstream listing
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 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 data types, formats, or structures (e.g., file types, geographic levels, user attributes)?"
Example:
Original: "Geographic search (counties, cities/towns/neighborhoods, custom provider areas)"
Split:
Story 1: Search by county
Story 2: Add city/town/neighborhood search
Story 3: Add custom provider area search
Options:
1. Yes, different data types → "List the data variations"
2. No, single data type → Continue to Pattern 5
If YES: Agent generates one story per data variation (deliver simplest first).
Pattern 5: Data Entry Methods
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:
Original: "Search with calendar date picker"
Split:
Story 1: Search by date (basic text input: "YYYY MM DD")
Story 2: Add visual calendar picker UI
Options:
1. Yes, fancy UI elements → "Describe the UI enhancements"
2. No, basic UI only → Continue to Pattern 6
If YES: Agent generates Story 1 = basic input, Story 2+ = UI enhancements.
Pattern 6: Major Effort
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:
Original: "Accept credit card payments (Visa, Mastercard, Amex, Discover)"
Split:
Story 1: Accept Visa payments (build full payment infrastructure)
Story 2: Add Mastercard, Amex, Discover support (trivial additions)
⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.
Options:
1. Yes, major effort pattern → "What's the first implementation + what are the additions?"
2. No, no infrastructure work → Continue to Pattern 7
If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.
Pattern 7: Simple/Complex
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:
Original: "Flight search (with max stops, nearby airports, flexible dates)"
Split:
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)
S