Epic Breakdown Techniques | Story Slicing

Break epics into 2-3 day stories using workflow, user type, or business rule techniques. Each slice should deliver independent value in one sprint.

6 min read

Epics are large work items that must be broken down for delivery. Good breakdown creates valuable, independently deliverable stories. Bad breakdown creates arbitrary slices that deliver no value alone. This guide covers effective epic breakdown.

Breakdown Approaches

Approach	Best For
Workflow steps	Processes
User types	Multiple personas
Business rules	Complex logic
CRUD	Data features

Breakdown Techniques

Common Patterns

EPIC BREAKDOWN TECHNIQUES
═════════════════════════

BY WORKFLOW STEP:
─────────────────────────────────────
Epic: User checkout

Story 1: Add to cart
Story 2: View cart
Story 3: Enter shipping
Story 4: Enter payment
Story 5: Confirm order
Story 6: Order confirmation email

Each step = deliverable slice

BY USER TYPE:
─────────────────────────────────────
Epic: User dashboard

Story 1: Dashboard for free users
Story 2: Dashboard for pro users
Story 3: Dashboard for admin users

Each persona = slice

BY BUSINESS RULE:
─────────────────────────────────────
Epic: Discount system

Story 1: Percentage discounts
Story 2: Fixed amount discounts
Story 3: Buy X get Y discounts
Story 4: Stacking multiple discounts

Each rule = slice

BY CRUD OPERATION:
─────────────────────────────────────
Epic: Project management

Story 1: Create project
Story 2: View project
Story 3: Update project
Story 4: Delete project
Story 5: List projects

Each operation = slice

More Techniques

MORE BREAKDOWN PATTERNS
═══════════════════════

BY HAPPY PATH vs EDGE CASES:
─────────────────────────────────────
Epic: Payment processing

Story 1: Successful payment (happy path)
Story 2: Handle declined card
Story 3: Handle network timeout
Story 4: Handle duplicate submission
Story 5: Handle refunds

Happy path first, then edges

BY PLATFORM:
─────────────────────────────────────
Epic: Mobile app

Story 1: iOS app
Story 2: Android app
Story 3: Tablet optimization

Each platform = slice

BY DATA VARIATION:
─────────────────────────────────────
Epic: Report generation

Story 1: Report for single project
Story 2: Report across projects
Story 3: Custom date ranges
Story 4: Export formats

Data complexity = slices

BY INTERFACE:
─────────────────────────────────────
Epic: API integration

Story 1: UI for integration
Story 2: API endpoint
Story 3: Webhook receiver
Story 4: Batch import

Each interface = slice

Vertical Slicing

Full-Stack Slices

VERTICAL SLICING
════════════════

HORIZONTAL (Avoid):
─────────────────────────────────────
Epic: User registration

Layer slices (bad):
├── Story: Create database schema
├── Story: Build backend API
├── Story: Create frontend form
├── Story: Add validation
└── No value until all done

VERTICAL (Prefer):
─────────────────────────────────────
Epic: User registration

Value slices (good):
├── Story: Register with email
│   ├── UI: email form
│   ├── API: create user
│   ├── DB: store user
│   └── Value: can register!
│
├── Story: Add password requirements
├── Story: Add email verification
└── Each story = working feature

VERTICAL SLICE DIAGRAM:
─────────────────────────────────────
       UI    API    DB
       │      │     │
Story1 ├──────┼─────┤  ← Full feature
       │      │     │
Story2 ├──────┼─────┤  ← Full feature
       │      │     │
Story3 ├──────┼─────┤  ← Full feature

Not:
       UI    API    DB
       │      │     │
Story1 ├──────┼─────│  ← Just UI
       │      │     │
Story2 │──────┼─────│  ← Just API
       │      │     │
Story3 │──────┼─────┤  ← Just DB

Validation

Checking Your Breakdown

VALIDATING BREAKDOWN
════════════════════

INVEST CRITERIA:
─────────────────────────────────────
Each story should be:
├── I - Independent (not dependent)
├── N - Negotiable (not rigid)
├── V - Valuable (delivers value)
├── E - Estimable (team can size)
├── S - Small (fits in sprint)
├── T - Testable (can verify)
└── Quality check

QUESTIONS TO ASK:
─────────────────────────────────────
├── Can we demo this story alone?
├── Does it deliver user value?
├── Can we ship just this?
├── Is it clear what "done" means?
├── Can team estimate it?
├── Does it fit in one sprint?
└── Validation questions

TOO SMALL:
─────────────────────────────────────
Signs:
├── No value without others
├── Just a task, not a story
├── Takes hours, not days
├── Can't be tested alone
└── May need to combine

TOO LARGE:
─────────────────────────────────────
Signs:
├── Won't fit in sprint
├── Can't estimate confidently
├── Many acceptance criteria
├── "And then and then..."
├── Multiple user types
└── Need to split further

GitScrum Support

Tracking Breakdown

GITSCRUM FOR EPICS
══════════════════

EPIC TRACKING:
─────────────────────────────────────
├── Create epic
├── Link stories to epic
├── Epic progress visible
├── Rollup of story status
└── Hierarchical view

BREAKING DOWN:
─────────────────────────────────────
Process:
├── Create epic with full scope
├── Create child stories
├── Link to epic
├── Estimate stories
├── Pull into sprints
└── Managed breakdown

PROGRESS:
─────────────────────────────────────
├── Epic shows % complete
├── Remaining stories visible
├── Sprint-by-sprint delivery
├── Stakeholder can see progress
└── Transparency

Best Practices

For Epic Breakdown

Vertical slices — Full-stack value

INVEST stories — Quality check

Demo-able — Can show to user

Sprint-sized — Fits in iteration

Multiple techniques — Right tool for job

Anti-Patterns

BREAKDOWN MISTAKES:
✗ Horizontal layer slices
✗ Technical-only stories
✗ No value until end
✗ Stories too large
✗ Stories too small
✗ Arbitrary splits
✗ Long dependency chains
✗ No clear done criteria