← Back to blog

Epics, features and stories: how to break down work

user-stories backlog management

“As an admin, I want a complete reporting system” — that won’t fit in a single sprint. It needs to be broken down. But how do you split it efficiently without losing sight of the value being delivered?

The work hierarchy

EPIC (months)
  └── FEATURE (sprints)
        └── USER STORY (days)
              └── TASK (hours)

Epic

A large product initiative. Takes months to complete.

“Complete loyalty program”

Feature

A specific capability within the epic. May take 1–3 sprints.

“Loyalty points system”

User Story

A unit of value delivered to the user. Fits in a single sprint (ideally a few days).

“As a customer, I want to see my points balance on my account page.”

Task

A technical step to implement the story. Measured in hours.

“Create GET /users/:id/points endpoint”

Decomposition techniques

1. By workflow

Break down each stage of the user’s journey:

  • Sign up → Log in → Search → Cart → Checkout → Payment

Epic: “Checkout”

  • Stories: address, shipping, payment, confirmation, coupon

2. By business rule

Variations of rules within a single feature:

  • Credit card payment
  • Bank slip payment
  • Instant transfer (PIX) payment
  • Points balance payment

3. By user type

Different personas have different needs:

Epic: “Dashboard”

  • Stories: customer dashboard, seller dashboard, admin dashboard

4. Vertical vs Horizontal

Vertical decomposition (recommended): Each story delivers end to end: UI + API + Database

Story 1: “As a customer, I want to pay by credit card” → Card UI (frontend) + processing (backend) + record (database)

Horizontal decomposition (avoid): Separate layers: “Build all APIs”, “Build all frontend”

Problem: no value is delivered until everything is done.

Criteria to know you’ve broken it down enough

A story is well-decomposed when:

  • Fits comfortably in a single sprint (max 5–8 points)
  • Has clear acceptance criteria
  • Delivers independent value
  • The team can estimate it with confidence

Common anti-patterns

The micro-story

“As a user, I want the button to be blue.” — That’s a design detail, not a story.

The never-ending story

“As an admin, I want to manage everything.” — That’s an epic disguised as a story. If the estimate lands on 21 or ?, it’s too big.

Circular dependency

Story A needs B which needs A. This means the decomposition didn’t respect independence.

Estimation by level

  • Epic: T-Shirt sizing (S, M, L, XL) — rough estimate for roadmap planning
  • Feature: Planning Poker with high values (13, 20, 40) — still has room for error
  • Story: Planning Poker with precision (0.5, 1, 2, 3, 5, 8, 13) — standard scale
  • Task: Hours — for the developer’s day-to-day

Conclusion

Good stories are the result of intelligently breaking down large epics. The key is to split by value delivered to the user, not by technical layers. Each story should be independent, testable, and deliver something useful on its own.