SKILL.md

--- frontmatter

name: epic-decomposition-planner
description: Use when breaking large initiatives into deliverable pieces. Use after epic scoped. Produces story breakdown, dependency mapping, suggested sequencing, and MVP definition.

Epic Decomposition Planner

Overview

Break down large initiatives (epics) into implementable stories with clear sequencing and dependencies. Enables incremental value delivery while maintaining coherent user experience.

Core principle: Decompose for value delivery, not just task breakdown. Each slice should be usable, not just "the backend part."

When to Use

•Epic too large for a single sprint
•Planning multi-sprint initiatives
•Defining MVP scope
•Creating release plan for large feature
•Identifying parallelizable work streams

Output Format

yaml

epic_decomposition:
  epic:
    id: "[EPIC-ID]"
    title: "[Epic title]"
    description: "[What this epic accomplishes]"
    business_value: "[Why we're doing this]"
    success_criteria: "[How we know it's done]"
    estimated_total_size: "[Total points estimate]"
  
  user_journey:
    primary_flow:
      - step: "[User action 1]"
        capability_needed: "[What system must do]"
      - step: "[User action 2]"
        capability_needed: "[What system must do]"
  
  mvp_definition:
    scope: "[Minimum for value delivery]"
    excluded_from_mvp:
      - feature: "[Nice-to-have excluded]"
        reason: "[Why deferred]"
        when: "[Trigger to reconsider]"
    estimated_mvp_size: "[Points]"
    estimated_mvp_sprints: "[Number]"
  
  stories:
    - id: "[STORY-01]"
      title: "[Story title]"
      size: "[Points]"
      slice_type: "[Horizontal | Vertical | Spike]"
      value_delivered: "[What user can do after]"
      in_mvp: [true | false]
      sequence: "[Phase number]"
      dependencies: ["[STORY-ID]"]
      parallelizable_with: ["[STORY-ID]"]
  
  phases:
    - phase: 1
      name: "[Phase name]"
      goal: "[What's accomplished]"
      stories: ["[STORY-01]", "[STORY-02]"]
      estimated_sprints: "[N]"
      deliverable: "[What ships]"
    
    - phase: 2
      name: "[Phase name]"
      goal: "[What's accomplished]"
      depends_on_phase: 1
      stories: ["[STORY-03]", "[STORY-04]"]
      estimated_sprints: "[N]"
      deliverable: "[What ships]"
  
  dependency_map:
    critical_path:
      - "[STORY-01] → [STORY-03] → [STORY-05]"
    parallel_tracks:
      - track: "Backend"
        stories: ["[STORY-02]", "[STORY-04]"]
      - track: "Frontend"
        stories: ["[STORY-06]", "[STORY-07]"]
  
  risks:
    - risk: "[Technical or scope risk]"
      affected_stories: ["[STORY-ID]"]
      mitigation: "[How to address]"
  
  spike_candidates:
    - question: "[What we need to learn]"
      timeboxed_effort: "[Days]"
      decision_enabled: "[What we can decide after]"

Slicing Techniques

Vertical Slicing (Preferred)

Complete thin slices through all layers:

code

❌ Horizontal Slicing        ✅ Vertical Slicing
┌─────────────────────┐      ┌─────────────────────┐
│ All UI              │      │ Feature A │ B │ C   │
├─────────────────────┤      │     UI    │UI │UI   │
│ All Business Logic  │      │     BL    │BL │BL   │
├─────────────────────┤      │     DB    │DB │DB   │
│ All Database        │      │           │   │     │
└─────────────────────┘      └─────────────────────┘
Sprint 1-2-3 waiting        Each vertical is deployable

Slicing Patterns

Pattern	When to Use	Example
By user type	Different users, different needs	Admin vs End-user features
By workflow step	Sequential process	Step 1 checkout, Step 2 payment
By data variation	Same action, different data	Single item vs bulk upload
By business rule	Complex rules	Basic rules first, edge cases later
By quality level	MVP vs polished	Manual fallback, then automation
By interface	Multiple access points	Web first, API later, mobile last

Slicing Examples

E-commerce Checkout Epic:

yaml

stories:
  - title: "Single item, credit card, standard shipping"
    slice: "MVP happy path"
    value: "Core purchase flow works"
    
  - title: "Multiple items in cart"
    slice: "By data variation"
    value: "Full cart experience"
    
  - title: "Alternative payment (PayPal)"
    slice: "By business rule"
    value: "Payment flexibility"
    
  - title: "Express shipping option"
    slice: "By workflow step"
    value: "Shipping choice"
    
  - title: "Guest checkout (no account)"
    slice: "By user type"
    value: "Reduced friction"

MVP Definition Framework

Must Have vs Nice to Have

Question	Must Have	Nice to Have
Can we deliver value without it?	No	Yes
Will users accept workaround?	No	Yes
Is it regulatory/compliance?	Often yes	Rarely
Does it address core problem?	Yes	Partially

MVP Scoping Template

yaml

mvp_scope:
  included:
    - feature: "Core user action"
      rationale: "Primary value proposition"
    - feature: "Essential validation"
      rationale: "Prevents bad data"
  
  excluded:
    - feature: "Bulk operations"
      rationale: "Low initial volume, manual workaround exists"
      reconsider_when: "Volume > 100/day"
    
    - feature: "Advanced reporting"
      rationale: "Basic metrics sufficient for launch"
      reconsider_when: "User feedback requests it"

Dependency Mapping

Types of Dependencies

Type	Description	Risk Level
Finish-to-Start	B can't start until A finishes	High
Start-to-Start	B can start when A starts	Medium
Shared Resource	Both need same person/team	Medium
External	Depends on outside team/vendor	High

Dependency Visualization

code

Phase 1                    Phase 2                  Phase 3
┌─────────┐               ┌─────────┐              ┌─────────┐
│ Story 1 │──────────────>│ Story 3 │─────────────>│ Story 5 │
└─────────┘      F-S      └─────────┘      F-S     └─────────┘
                               ↑
┌─────────┐                    │
│ Story 2 │────────────────────┘ (parallel to Story 1)
└─────────┘

Legend: F-S = Finish-to-Start dependency

Sequencing Strategy

Prioritization Factors

•User value - What delivers most value soonest?
•Technical dependencies - What must exist for other work?
•Risk reduction - What resolves uncertainty earliest?
•Resource availability - What matches team capacity?

Sequencing Heuristics

Principle	Rationale
Foundation first	Infrastructure enables features
Happy path first	Prove core value before edge cases
Risky items early	Fail fast, learn early
Integration points early	Surface cross-team issues
User-facing changes last	Minimize rework

Spike Planning

When to spike (timeboxed research):

yaml

spike_triggers:
  - "We don't know if this technology will work"
  - "Integration complexity is unknown"
  - "Performance requirements are unclear"
  - "Team has no experience with this domain"

spike_output:
  - question: "Can we achieve <1s response with ML model?"
    timebox: "3 days"
    success_criteria: "Proof-of-concept benchmarks"
    decision: "Proceed with ML vs simpler approach"

Common Mistakes

Mistake	Problem	Fix
Horizontal layers	No deliverable value per slice	Vertical slices
Everything is MVP	MVP too large	Ruthless prioritization
No dependencies mapped	Surprise blockers	Explicit dependency graph
Stories too large	Can't fit in sprint	Further decomposition
Technical stories only	No user value	Frame as user outcomes
Ignoring sequencing	Blocked work	Critical path analysis

Decomposition Checklist

Before planning sprints: