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

- **Type:** Skill
- **Install:** `agentstack add skill-getcrew44-crew44-epic-breakdown-advisor`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [getcrew44](https://agentstack.voostack.com/s/getcrew44)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [getcrew44](https://github.com/getcrew44)
- **Source:** https://github.com/getcrew44/crew44/tree/main/daemon/internal/presets/defaultcrew/skills/product/epic-breakdown-advisor
- **Website:** https://crew44.io

## Install

```sh
agentstack add skill-getcrew44-crew44-epic-breakdown-advisor
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

## 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 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 5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.

---

**If stories are still too large, re-apply patterns starting at Pattern 1.**
```

---

## Examples

### Example 1: Pattern 1 Applied (Workflow Steps - Thin End-to-End)

**Epic:** "Publish blog post (requires editorial review, legal approval, staging)"

**Pre-Split Validation:** ✅ Passes INVEST

**Pattern 1:** "Does this have workflow steps?" → YES ✅

**❌ Wrong Split (Step-by-Step):**
1. Editorial review story
2. Legal approval story
3. Publish story
→ Problem: Story 1 doesn't deliver value (users see nothing)

**✅ Right Split (Thin End-to-End):**
1. **Publish post (simple path)** — Author uploads, post goes live immediately (no reviews)
2. **Add editorial review** — Post now waits for editor approval before going live
3. **Add legal approval** — Post waits for legal + editorial before going live

**Why this works:** Each story delivers **full workflow**, just with increasing sophistication.

---

### Example 2: Pattern 2 Applied (CRUD Operations)

**Epic:** "Manage user profiles"

**Pattern 2:** "Does this say 'manage'?" → YES ✅ (signals CRUD)

**Split:**
1. Create user profile
2. View user profile details
3. Edit user profile info
4. Delete user profile

**Split Evaluation:**
- ✅ **Reveals low-value work:** After analysis, "Delete profile" is rarely used → deprioritize
- ✅ **Equal-sized stories:** Each 1-2 days

---

### Example 3: Pattern 7 Applied (Simple/Complex)

**Epic:** "Flight search with max stops, nearby airports, flexible dates"

**Pattern 7:** "What's the simplest version?" → Basic search ✅

**Split:**
1. Basic flight search (origin, destination, date) — **Core value**
2. Add max stops filter — **Enhancement**
3. Add nearby airports option — **Enhancement**
4. Add flexible dates option — **Enhancement**

**Split Evaluation:**
- ✅ **Reveals low-value work:** User research shows "flexible dates" rarely used → kill or defer
- ✅ **Equal-sized stories:** Story 1 = 3 days, others = 1 day each

---

### Example 4: Iterative Splitting (Multiple Patterns)

**Epic:** "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"

**First Pass - Pattern 1 (Workflow):** YES ✅
- Story 1: Add items to cart
- Story 2: Apply discount
- Story 3: Complete payment

**Check Story 2 ("Apply discount"):** Still 4 days → Too large, re-split

**Second Pass on Story 2 - Pattern 3 (Business Rules):** YES ✅
- Story 2a: Apply member discount (10%)
- Story 2b: Apply VIP discount (20%)
- Story 2c: Apply first-time discount (5%)

**Check Story 3 ("Complete payment"):** Still 5 days → Too large, re-split

**Third Pass on Story 3 - Pattern 6 (Major Effort):** YES ✅
- Story 3a: Accept Visa payments (build payment infrastructure)
- Story 3b: Add Mastercard, Amex support

**Final Breakdown:** 6 stories, all 1-2 days each

---

## Common Pitfalls

### Pitfall 1: Skipping Pre-Split Validation
**Symptom:** Jump straight to splitting without checking INVEST

**Consequence:** Split a story that shouldn't be split (e.g., not Valuable = technical task)

**Fix:** Always run Step 1 (INVEST check) before Step 2 (splitting patterns)

---

### Pitfall 2: Step-by-Step Workflow Splitting (Pattern 1 Done Wrong)
**Symptom:** Story 1 = "Editorial review," Story 2 = "Legal approval"

**Consequence:** Stories don't deliver end-to-end value

**Fix:** Each story should cover **full workflow** (thin end-to-end slice), just with increasing sophistication

---

### Pitfall 3: Horizontal Slicing (Technical Layers)
**Symptom:** "Story 1: Build API. Story 2: Build UI."

**Consequence:** Neither story delivers user value

**Fix:** Vertical slicing—each story includes front-end + back-end to deliver observable user behavior

---

### Pitfall 4: Forcing a Pattern That Doesn't Fit
**Symptom:** "We'll split by workflow even though there's no sequence"

**Consequence:** Arbitrary, meaningless split

**Fix:** If pattern doesn't apply, say NO and continue to next pattern

---

### Pitfall 5: Not Re-Splitting Large Stories
**Symptom:** Split epic into 3 stories, but each is still 5+ days

**Consequence:** Stories too large for sprint

**Fix:** **Restart at Pattern 1** for each large story until all are 1-5 days

---

### Pitfall 6: Ignoring Split Evaluation (Step 3)
**Symptom:** Split but don't evaluate if it reveals low-value work

**Consequence:** Miss opportunity to eliminate waste

**Fix:** After splitting, ask: "Does this r

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [getcrew44](https://github.com/getcrew44)
- **Source:** [getcrew44/crew44](https://github.com/getcrew44/crew44)
- **License:** MIT
- **Homepage:** https://crew44.io

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-getcrew44-crew44-epic-breakdown-advisor
- Seller: https://agentstack.voostack.com/s/getcrew44
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.