9 min read • Guide 742 of 877
Story Splitting Techniques
Large stories create risk and delay feedback. GitScrum helps teams track split stories with parent-child relationships and progress rollups.
Why Split Stories
The Problem with Large Stories
LARGE STORY PROBLEMS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LARGE STORY (13 points): │
│ "As a user, I can manage my account settings" │
│ │
│ WHAT HAPPENS: │
│ │
│ Day 1: "Working on it" │
│ Day 2: "Still working on it" │
│ Day 3: "Making progress" │
│ Day 4: "Almost done" │
│ Day 5: "90% done" │
│ Day 6: "Just finishing up" │
│ Day 7: "Found an issue" │
│ Day 8: "Actually 50% done" │
│ Day 9-15: More of the same... │
│ │
│ PROBLEMS: │
│ │
│ ❌ No feedback until done │
│ ❌ "90% done" for days │
│ ❌ Hard to estimate accurately │
│ ❌ Risk hidden until too late │
│ ❌ Blocks other work │
│ ❌ Can't ship partial value │
│ ❌ Sprint commitment unclear │
│ │
│ THE ALTERNATIVE: │
│ │
│ Split into 5 stories (2-3 points each) │
│ Ship 1-2 per day │
│ Get feedback continuously │
│ Adapt based on learning │
└─────────────────────────────────────────────────────────────┘
Benefits of Small Stories
SMALL STORY BENEFITS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PREDICTABLE FLOW: │
│ • Stories complete daily │
│ • Burndown is smooth │
│ • Progress visible │
│ │
│ BETTER ESTIMATES: │
│ • Less unknown in smaller scope │
│ • Easier to compare │
│ • More accurate velocity │
│ │
│ FASTER FEEDBACK: │
│ • Ship to users sooner │
│ • Catch issues early │
│ • Course correct quickly │
│ │
│ LOWER RISK: │
│ • Less rework if wrong │
│ • Easier to pivot │
│ • Fewer integration issues │
│ │
│ TEAM BENEFITS: │
│ • More satisfying (completion!) │
│ • Easier collaboration │
│ • Less context to share │
│ │
│ IDEAL SIZE: │
│ • 1-3 days of work │
│ • 1-5 story points │
│ • Fits in a sprint easily │
│ • Delivers something usable │
└─────────────────────────────────────────────────────────────┘
Splitting Techniques
By Workflow Steps
SPLIT BY WORKFLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL STORY: │
│ "As a user, I can manage my profile" │
│ (Too big - 13 points) │
│ │
│ IDENTIFY WORKFLOW STEPS: │
│ View → Edit → Save → Validate → Notify │
│ │
│ SPLIT STORIES: │
│ │
│ 1. "As a user, I can view my current profile" │
│ (2 points) - Display only │
│ │
│ 2. "As a user, I can edit my name and email" │
│ (3 points) - Basic editing │
│ │
│ 3. "As a user, I can upload a profile photo" │
│ (3 points) - Photo handling │
│ │
│ 4. "As a user, I can change my password" │
│ (3 points) - Security sensitive │
│ │
│ 5. "As a user, I receive email when profile changes" │
│ (2 points) - Notification │
│ │
│ EACH STORY: │
│ ✓ Delivers value independently │
│ ✓ Can be tested independently │
│ ✓ Can ship independently │
└─────────────────────────────────────────────────────────────┘
By Data Variations
SPLIT BY DATA/INPUT TYPE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL STORY: │
│ "As a user, I can pay for my order" │
│ (Too big - 13 points) │
│ │
│ IDENTIFY VARIATIONS: │
│ Credit card, PayPal, Apple Pay, Bank transfer │
│ │
│ SPLIT STORIES: │
│ │
│ 1. "As a user, I can pay with credit card" │
│ (5 points) - Start with most common │
│ │
│ 2. "As a user, I can pay with PayPal" │
│ (3 points) - Second option │
│ │
│ 3. "As a user, I can pay with Apple Pay" │
│ (3 points) - Third option │
│ │
│ 4. "As a user, I can pay via bank transfer" │
│ (3 points) - Fourth option │
│ │
│ BENEFITS: │
│ • Ship credit card first (most value) │
│ • Learn from each payment type │
│ • Can defer less common types │
│ │
│ OTHER DATA SPLITS: │
│ • By user type (admin, regular, guest) │
│ • By file type (PDF, CSV, Excel) │
│ • By region (US, EU, Asia) │
└─────────────────────────────────────────────────────────────┘
By Operations
SPLIT BY CRUD OPERATIONS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL STORY: │
│ "As an admin, I can manage products" │
│ (Too big - too vague) │
│ │
│ CRUD BREAKDOWN: │
│ │
│ CREATE: │
│ "As an admin, I can add a new product" │
│ (3 points) │
│ │
│ READ: │
│ "As an admin, I can view all products" │
│ (2 points) │
│ │
│ UPDATE: │
│ "As an admin, I can edit product details" │
│ (3 points) │
│ │
│ DELETE: │
│ "As an admin, I can remove a product" │
│ (2 points) │
│ │
│ FURTHER SPLITS IF NEEDED: │
│ │
│ "Add product" might become: │
│ • Add product with basic info │
│ • Add product photos │
│ • Add product pricing │
│ • Add product variants │
└─────────────────────────────────────────────────────────────┘
By Interface
SPLIT BY INTERFACE/PLATFORM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL STORY: │
│ "As a user, I can view my dashboard" │
│ (13 points - includes web and mobile) │
│ │
│ SPLIT BY PLATFORM: │
│ │
│ 1. "As a web user, I can view my dashboard" │
│ (5 points) - Web version first │
│ │
│ 2. "As a mobile user, I can view my dashboard" │
│ (5 points) - Mobile adaptation │
│ │
│ SPLIT BY COMPONENT: │
│ │
│ Dashboard might become: │
│ 1. "...I can see my activity summary" │
│ 2. "...I can see recent transactions" │
│ 3. "...I can see quick actions" │
│ 4. "...I can see notifications" │
│ │
│ SPLIT BY QUALITY: │
│ │
│ 1. Basic dashboard (text only) │
│ 2. Dashboard with charts │
│ 3. Dashboard with real-time updates │
│ 4. Dashboard with customization │
└─────────────────────────────────────────────────────────────┘
By Complexity
SPLIT BY HAPPY PATH / EDGE CASES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL STORY: │
│ "As a user, I can checkout my order" │
│ (Too big - includes all edge cases) │
│ │
│ SPLIT APPROACH: │
│ │
│ HAPPY PATH FIRST: │
│ 1. "...I can checkout with valid payment" │
│ (5 points) - Assumes everything works │
│ │
│ ERROR HANDLING: │
│ 2. "...I see clear error if payment fails" │
│ (2 points) - Declined cards │
│ │
│ EDGE CASES: │
│ 3. "...I can retry if payment times out" │
│ (2 points) - Network issues │
│ │
│ 4. "...I'm protected from duplicate orders" │
│ (3 points) - Double-click protection │
│ │
│ VALIDATION: │
│ 5. "...I'm told if card is expired" │
│ (1 point) - Validation rule │
│ │
│ BENEFITS: │
│ • Ship happy path first │
│ • Add robustness incrementally │
│ • Can defer rare edge cases │
│ • Users get value earlier │
└─────────────────────────────────────────────────────────────┘
Tracking Split Stories
GitScrum Structure
ORGANIZING SPLIT STORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EPIC: Account Management │
│ │
│ └── STORY: Profile management (original - closed) │
│ │ │
│ └── CHILD STORIES: │
│ ├── View profile (3 pts) ✅ Done │
│ ├── Edit basic info (3 pts) ✅ Done │
│ ├── Upload photo (3 pts) 🔄 In Progress │
│ ├── Change password (3 pts) ⬜ To Do │
│ └── Email notifications (2 pts) ⬜ To Do │
│ │
│ GITSCRUM VIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Profile Management ││
│ │ Progress: ██████░░░░ 43% (6/14 points) ││
│ │ ││
│ │ ☑ View profile (3 pts) ││
│ │ ☑ Edit basic info (3 pts) ││
│ │ 🔄 Upload photo (3 pts) ││
│ │ ☐ Change password (3 pts) ││
│ │ ☐ Email notifications (2 pts) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ROLLUP: │
│ Parent story tracks total progress │
│ Each child is independent and deliverable │
└─────────────────────────────────────────────────────────────┘
When Not to Split
SPLITTING LIMITS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DON'T SPLIT IF: │
│ │
│ PIECES HAVE NO VALUE: │
│ ❌ "Create database table" │
│ ❌ "Write API endpoint" │
│ ❌ "Build UI form" │
│ → These are tasks, not stories │
│ → Group into one valuable story │
│ │
│ TOO SMALL ALREADY: │
│ ❌ 1-point stories split further │
│ → Overhead exceeds value │
│ → Just do it │
│ │
│ ARTIFICIALLY SPLIT: │
│ ❌ "Part 1", "Part 2", "Part 3" │
│ → Not independently valuable │
│ → Find natural split points │
│ │
│ BETTER APPROACH: │
│ │
│ Ask: "Can a user do something useful with just this?" │
│ │
│ Yes → Good split │
│ No → Keep together or find different split │
│ │
│ "VIEW + EDIT" is better than "BACKEND + FRONTEND" │
│ Horizontal slices > Vertical slices │
└─────────────────────────────────────────────────────────────┘