Too Big!
User can manage their complete profile
Basic profile editing
5Profile photo upload
3Privacy & preferences
5Security (2FA)
5Before: 1 story @ 21 points (won't fit in sprint)→After: 4 stories @ 3-5 points each (all deliverable)
Why Stories Need Splitting
Fits in a sprint
Problem: Stories larger than the team can complete in one sprint create failed commitments
Solution: Split into sprint-sized chunks that deliver incremental value
Faster feedback
Problem: Large stories delay learning and prevent course correction
Solution: Smaller stories get into users' hands faster, validating assumptions sooner
Reduced risk
Problem: Big stories mean "all or nothing" outcomes and wasted effort if requirements change
Solution: Small stories limit blast radius and allow pivoting without huge sunk costs
Signs a Story Is Too Big
Estimated at 13+ points
highIf your team's max story size is 8, anything 13+ won't fit
Takes multiple sprints
highStories should complete within one sprint cycle
Has multiple acceptance criteria
mediumMore than 5-6 criteria often means multiple stories hiding
Team estimates vary wildly
mediumSpread of 1 to 13 means unclear scope—definition problem
Uses "and" multiple times
medium"As a user I can X and Y and Z" = 3 stories, not 1
No one volunteers to pick it up
lowPsychological signal: story feels too overwhelming
9 Proven Splitting Patterns
SPIDR Framework: The first 5 patterns spell SPIDR—a popular mnemonic for story splitting. Use whichever pattern fits your story's structure.
Spike / Paths
Split by workflow paths or user journeys
Example: Payment processing
- ✓Credit card payment
- ✓PayPal payment
- ✓Bank transfer payment
Interface
Split by interface or platform type
Example: Multi-platform features
- ✓Upload photos via web
- ✓Upload photos via mobile app
- ✓Upload photos via API
Data
Split by data types, sources, or variations
Example: Import functionality
- ✓Import from CSV
- ✓Import from Google Contacts
- ✓Import from Outlook
Rules / Business Logic
Split by business rules or validation complexity
Example: Validation rules
- ✓Required field validation
- ✓Format validation
- ✓Business rule validation
Operations (CRUD)
Split by Create, Read, Update, Delete operations
Example: CRUD operations
- ✓Create product
- ✓View product list
- ✓Edit product
- ✓Delete product
Simple / Complex
Split by implementation complexity levels
Example: Feature with edge cases
- ✓Basic keyword search
- ✓Advanced filters
- ✓Saved search queries
Defer Performance
Build functional version first, optimize later
Example: Performance optimization
- ✓Analytics with 5-sec delay (functional)
- ✓Optimize to <1 sec (performance)
Break Out Spike
Separate research/learning from implementation
Example: Unknown technology
- ✓Research ML libraries (spike)
- ✓Implement recommendation engine
Acceptance Criteria
Turn each acceptance criteria into its own story
Example: Multi-criteria story
- ✓Profile fields & validation
- ✓Profile photo upload
- ✓Privacy settings
Anti-Patterns to Avoid
Horizontal slicing (by layer)
Why it's bad: Splitting by "frontend" and "backend" delivers no user value until both are done
Better approach: Vertical slicing—deliver one complete feature path end-to-end
Example: DON'T: Story 1 = API, Story 2 = UI. DO: Story 1 = Basic login flow (API + UI)
Technical tasks masquerading as stories
Why it's bad: "Refactor database schema" is a task, not a user story—no user value
Better approach: Combine technical work with value delivery: "Add user preferences (includes DB schema)"
Example: DON'T: "Migrate to PostgreSQL". DO: "User dashboard with new reporting (requires DB migration)"
Splitting by team member
Why it's bad: Assigning stories to individuals prevents collaboration and creates handoff delays
Better approach: Split by functionality, then let team swarm and collaborate
Example: DON'T: "Sarah's part" and "Mike's part". DO: "Feature A" and "Feature B"
Splitting too small
Why it's bad: Stories like "Change button color" create overhead—commit, review, deploy per tiny change
Better approach: Batch tiny changes into meaningful deliverable increments
Example: DON'T: 20 stories for UI polish. DO: 1-2 stories grouping related polish items
Split but maintain dependencies
Why it's bad: If Story B can't start until Story A completes, you haven't truly split the risk
Better approach: Make splits independent when possible, or clearly sequence them
Example: Identify dependency chains and see if you can break them with different approaches
Re-estimating Split Stories
Important: After splitting, re-estimate each new story from scratch. Don't just divide the original estimate—you'll often find the sum changes as hidden complexity surfaces or is eliminated.
Scenario 1: Split into 3 equal-sized pieces
Original
13 points
Naive thinking
13 ÷ 3 ≈ 4-5 points each
Reality
Usually 3 + 5 + 5 = 13 total
Why: First story includes setup overhead; others benefit from established patterns
Scenario 2: Split by complexity (simple/complex)
Original
8 points
Naive thinking
2 (simple) + 6 (complex)
Reality
Often 3 (simple) + 8 (complex) = 11 total
Why: Breaking apart reveals hidden complexity you missed in the original estimate
Scenario 3: Break out spike from implementation
Original
13 points
Naive thinking
Spike (2) + Implementation (11)
Reality
Spike (5) + Implementation (5) = 10 total
Why: Spike reduces uncertainty, making implementation easier than originally thought
Rule of thumb: After splitting and re-estimating, the total points often increase by 10-20% as the team discovers details they glossed over in the original estimate. This is a feature, not a bug—you're surfacing real complexity.
✓ Key Takeaways
- 1Split stories when they're estimated at 13+ points, span multiple sprints, or have 6+ acceptance criteria
- 2Use SPIDR patterns (Spike/Paths, Interface, Data, Rules) plus CRUD, complexity, performance, and acceptance criteria splits
- 3Always split vertically (end-to-end value), never horizontally by technical layer or team member
- 4Re-estimate each split story independently—don't just divide the original estimate
- 5Avoid splitting too small (overhead) or maintaining dependencies between split stories (defeats the purpose)
- 6Total points often increase 10-20% after splitting as hidden complexity surfaces—this is expected and healthy
Before & After: Story Size Comparison
Before Splitting
⚠️ Won't fit in a 2-week sprint
⚠️ Team can't commit with confidence
⚠️ No incremental value delivery
After Splitting
✓ All stories fit in sprint
✓ Each delivers standalone value
✓ Team can commit with confidence
Ready to Estimate Your Split Stories?
Use our free planning poker tool to estimate your newly split user stories with your team in real-time.
Start Free Planning Session