Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
SKILL.md wird angezeigt
SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
epic-breakdown-advisor
argument-hint
[epic to split]
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?"]
theme
pm-artifacts
estimated_time
20-30 min
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
Pre-Split Validation: Check if story satisfies INVEST criteria (except "Small")
Apply Splitting Patterns: Work through 9 patterns sequentially until one fits
Evaluate Splits: Choose the split that reveals low-value work or produces equal-sized stories
The 9 Splitting Patterns (In Order)
Workflow Steps — Thin end-to-end slices, not step-by-step
Operations (CRUD) — Create, Read, Update, Delete as separate stories
Business Rule Variations — Different rules = different stories
Data Variations — Different data types/structures
— Simple UI first, fancy UI later
Data Entry Methods
Major Effort — "Implement one + add remaining"
Simple/Complex — Core simplest version first, variations later
Defer Performance — "Make it work" before "make it fast"
Break Out a Spike — Time-box investigation when uncertainty blocks splitting
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?"
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:
Yes, major effort pattern → "What's the first implementation + what are the additions?"
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:
Yes, can identify simplest core → "Describe the simplest version + what variations to defer"
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)
Story 2: Optimize search to <100ms (add caching, indexing)
Options:
Yes, can defer optimization → "What's the functional version + what's the optimization?"
No, performance is essential → Continue to Pattern 9
If YES: Agent generates Story 1 = functional, Story 2 = optimize.
Pattern 9: Break Out a Spike
Key insight: Last resort when uncertainty prevents splitting. Time-box investigation to answer specific questions, then split implementation story with better understanding.
Agent says:
"None of patterns 1-8 apply, which suggests high uncertainty. Before splitting, run a spike to reduce uncertainty."
A spike is a time-boxed investigation (not a story), answering questions like:
Is this technically feasible?
Which approach performs best?
What does the API actually return?
Agent asks:
"What's the biggest unknown preventing you from splitting this epic?"
Options:
Technical feasibility — "Can we build this with our stack?"
Approach uncertainty — "Multiple ways to solve it, unclear which is best"
External dependency — "Don't know what third-party API provides"
Agent recommends:
→ "Run a 1-2 day spike to answer [question]. After the spike, come back and we'll split the epic with better understanding."
⚠️ Spikes produce learning, not shippable code. After the spike, restart at Pattern 1.
Step 3: Evaluate Split Quality
After splitting, evaluate using these criteria:
Agent asks:
1. Does this split reveal low-value work you can deprioritize or eliminate?
Good splits expose the 80/20 principle: most value concentrates in a small portion of functionality
Example: After splitting "Flight search" into 4 stories, you realize "flexible dates" is rarely used → deprioritize or kill it
2. Does this split produce more equally-sized stories?
Equal-sized stories give Product Owners greater prioritization flexibility
Example: Instead of one 10-day epic, five 2-day stories allow reordering mid-sprint
If split doesn't satisfy either criterion, try a different pattern.
Meta-Pattern Application
Across all patterns, follow this sequence:
Identify core complexity — What makes this epic hard?
List variations — What are all the different ways/cases/rules?
Reduce to one complete slice — Pick the simplest variation that still delivers end-to-end value
Make other variations separate stories
Cynefin Domain Considerations
Strategy shifts based on complexity domain:
Agent asks:
"How much uncertainty surrounds this epic?"
Options:
Low uncertainty (Obvious/Complicated domain) — "We know what to build; it's just engineering work"
→ Find all stories, prioritize by value/risk
High uncertainty (Complex domain) — "We're not sure what customers want or what will work"
→ Identify 1-2 learning stories; avoid exhaustive enumeration (work itself teaches what matters)
Chaos — "Everything is on fire; priorities shift daily"
→ Defer splitting until stability emerges; focus on stabilization first
Output: Generate Story Breakdown
# Epic Breakdown Plan**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]
---
## Story Breakdown### Story 1: [Title] (Simplest Complete Slice)**Summary:** [User-value-focused title]
**Use Case:**-**As a** [persona]
-**I want to** [action]
-**so that** [outcome]
**Acceptance Criteria:**-**Given:** [Preconditions]
-**When:** [Action]
-**Then:** [Outcome]
**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]
---
### Story 2: [Title] (First Variation)
[Repeat...]
---
### Story 3: [Title] (Second Variation)
[Repeat...]
---
## Split Evaluation
✅ **Does this split reveal low-value work?**- [Analysis: Which stories could be deprioritized/eliminated?]
✅ **Does this split produce equal-sized stories?**- [Analysis: Are stories roughly equal in effort?]
---
## INVEST Validation (Each Story)
✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each
---
## Next Steps1.**Review with team:** Do PM, design, engineering agree?
2.**Check for further splitting:** Are any stories still >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):
Editorial review story
Legal approval story
Publish story
→ Problem: Story 1 doesn't deliver value (users see nothing)
✅ Right Split (Thin End-to-End):
Publish post (simple path) — Author uploads, post goes live immediately (no reviews)
Add editorial review — Post now waits for editor approval before going live
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:
Create user profile
View user profile details
Edit user profile info
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:
Basic flight search (origin, destination, date) — Core value
Add max stops filter — Enhancement
Add nearby airports option — Enhancement
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)
