When a story is estimated at 13, 21, or "too big to estimate," it's not ready for sprint planning. Epics require decomposition before accurate estimation. Here's how to break down massive features into estimable stories.
Signs a Story Is Too Large
How do you know when a story is actually an epic in disguise? Watch for these red flags during estimation:
Wide Vote Spread
Votes cluster at 13+ or include "?" / "coffee cup" (too big). When half the team votes 8 and half votes 21, the story isn't understood well enough to estimate.
Excessive "Depends On" Statements
Team says "depends on..." more than 3 times. "Depends on which database we use, depends on mobile design, depends on API latency..."—too many unknowns.
Acceptance Criteria Overload
List has 10+ bullet points. Each acceptance criterion represents work. More than 7-8 criteria usually means multiple stories bundled together.
Multiple User Personas
Story spans multiple user types. "As a customer AND admin AND support agent" = 3 stories minimum.
Can't Finish in One Sprint
If you can't see the story completing in 5-7 days with one developer, it's too large. Split it.
Implementation Uncertainty
Team debates multiple implementation approaches. "Are we using REST or GraphQL? Microservice or monolith?" If fundamental architecture is unclear, spike first, estimate later.
Epic Decomposition Techniques
1. Slice by User Journey Steps
Example Epic: "Build user onboarding flow"
Break into sequential steps users take:
- Story 1: Email verification and account activation
- Story 2: Profile setup wizard (name, avatar, preferences)
- Story 3: Interactive tutorial walkthrough
- Story 4: First-time user dashboard customization
Each story delivers value independently. User can verify email without the tutorial existing yet.
2. Slice by Technical Layers
Example Epic: "Add multi-currency support"
Break by technical components:
- Story 1: Database schema for currency codes and exchange rates
- Story 2: Exchange rate API integration and caching
- Story 3: UI currency selector component
- Story 4: Historical transaction conversion for reporting
Useful for infrastructure work where user-facing changes require foundational tech.
3. Slice by CRUD Operations
Example Epic: "Admin panel for user management"
Break by Create/Read/Update/Delete:
- Story 1: View user list with filtering
- Story 2: View individual user details
- Story 3: Edit user roles and permissions
- Story 4: Deactivate/delete users
Common pattern for CRUD-heavy features.
4. Slice by User Roles
Example Epic: "Reporting dashboard"
Break by who uses it:
- Story 1: Manager view (team performance metrics)
- Story 2: Individual contributor view (personal stats)
- Story 3: Executive view (company-wide rollups)
Each role has different needs and permissions.
5. Slice by Happy Path vs Edge Cases
Example Epic: "Payment processing"
- Story 1: Happy path (successful credit card charge)
- Story 2: Declined payment handling
- Story 3: Retry logic for network failures
- Story 4: Refund processing
Deliver core value first, handle edge cases incrementally.
6. Spike First, Then Estimate
For truly unknown work, create a "spike" story:
- Timebox: 4-8 hours of research, no implementation
- Output: Written findings + decomposed stories with acceptance criteria
- Then estimate the decomposed stories with new knowledge
Spikes convert unknown complexity into estimable work. They're the "reconnaissance mission" before the full assault.
When to Use Which Technique
- User journey: Feature with clear workflow (onboarding, checkout)
- Technical layers: Infrastructure/refactoring work
- CRUD: Admin panels, data management UIs
- User roles: Different personas with distinct needs
- Happy path + edge cases: Risk management, payments, integrations
- Spike: Genuinely unknown territory (new tech, unclear requirements)
Mix techniques. One epic might slice by user journey, then each journey step slices by technical layers.
Decomposition Workshop Process
Run a 60-minute decomposition session:
- Present the epic (5 min): PO reads requirements and acceptance criteria
- Identify decomposition axis (10 min): Team votes on which technique to use
- Generate stories (20 min): Silent brainstorm on sticky notes, then consolidate
- Write acceptance criteria (15 min): Each story gets 3-5 testable conditions
- Sanity check (10 min): Can each story finish in one sprint? If not, decompose further
How Small is Small Enough?
Target 3-8 points per story. Stories under 3 points are fine (better too small than too large). Stories over 8 still need decomposition.
Aim for "bite-sized" stories that:
- Fit in one sprint
- One developer can own end-to-end
- Deliver testable value
- Have clear acceptance criteria
Common Decomposition Mistakes
Slicing Too Thin
Story: "Add Save button to form"—that's a task, not a story. No user value in isolation. Bundle it: "Build contact form with validation and save."
Waterfall in Disguise
- Story 1: Design
- Story 2: Backend API
- Story 3: Frontend UI
- Story 4: Testing
This creates dependencies. Better: vertical slices where each story includes design + backend + frontend + testing for one piece of functionality.
Decomposing Based on Estimation
"Story is 13 points, so let's split it into two 5-point stories." Arbitrary. Split based on functional boundaries, not to hit point targets.
After Decomposition: Re-Estimate
Original epic: 21 points
After decomposition: 5 stories of 3, 5, 5, 3, 8 = 24 points total
Wait, it INCREASED? Yes. Decomposition reveals hidden complexity. That's the point—better to know now than discover mid-sprint.
Tools for Epic Management
Alignlee lets you estimate epics at high level, then break into stories and re-estimate. Tracks original epic estimate vs. decomposed total for learning.
Start Epic Breakdown
Got a 13+ point story? Don't squeeze it into a sprint. Decompose first, then estimate accurately.