User Story Splitting Techniques | Sized Deliverables
Split large user stories into manageable pieces that fit in a sprint. GitScrum's parent tasks and labels track story fragments connected to the original epic.
8 min read
Large stories are risky and hard to estimate. GitScrum helps teams track split stories while maintaining connection to the original epic.
Why Split Stories
Benefits of Small Stories
SMALL STORY BENEFITS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LARGE STORY RISKS: │
│ ────────────────── │
│ ❌ Hard to estimate accurately │
│ ❌ May not fit in sprint │
│ ❌ Long feedback cycles │
│ ❌ High risk of rework │
│ ❌ Blocked progress │
│ ❌ "90% done" syndrome │
│ │
│ SMALL STORY BENEFITS: │
│ ───────────────────── │
│ ✅ Easier to estimate │
│ ✅ Fits in sprint │
│ ✅ Fast feedback │
│ ✅ Lower risk │
│ ✅ Visible progress │
│ ✅ Done is done │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SIZE GUIDELINE: │
│ │
│ TOO BIG (13+ points): │
│ • More than half the sprint │
│ • Split required │
│ │
│ BORDERLINE (8 points): │
│ • Consider splitting │
│ • Depends on complexity │
│ │
│ GOOD SIZE (1-5 points): │
│ • Can complete in 1-3 days │
│ • Fits well in sprint │
│ │
│ TOO SMALL (1 point): │
│ • Overhead of tracking costs more than work │
│ • Combine with related work │
└─────────────────────────────────────────────────────────────┘
Splitting Patterns
By Workflow Steps
SPLITTING BY WORKFLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATTERN: CRUD Operations │
│ │
│ ORIGINAL (21 points): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ As an admin, I want to manage users so that ││
│ │ I can control access to the system. ││
│ │ ││
│ │ This includes: ││
│ │ • Create users ││
│ │ • List users ││
│ │ • Edit users ││
│ │ • Delete users ││
│ │ • Assign roles ││
│ │ • Search/filter ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SPLIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. View user list (3 pts) ││
│ │ Basic list with name, email, status ││
│ │ ││
│ │ 2. Create new user (5 pts) ││
│ │ Form with validation, email notification ││
│ │ ││
│ │ 3. Edit user details (3 pts) ││
│ │ Update name, email, status ││
│ │ ││
│ │ 4. Delete/deactivate user (3 pts) ││
│ │ Soft delete with confirmation ││
│ │ ││
│ │ 5. Assign roles to user (5 pts) ││
│ │ Role picker, permission display ││
│ │ ││
│ │ 6. Search and filter users (3 pts) ││
│ │ By name, email, role, status ││
│ │ ││
│ │ Total: 22 pts (in 6 smaller stories) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Each story delivers value independently │
│ Can ship after story 1-2 │
└─────────────────────────────────────────────────────────────┘
By User Type
SPLITTING BY PERSONA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATTERN: Different Users, Different Needs │
│ │
│ ORIGINAL (13 points): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ As a user, I want a dashboard so that I can ││
│ │ see relevant metrics and actions. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROBLEM: "User" is too generic │
│ Different users need different things │
│ │
│ SPLIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Admin dashboard (5 pts) ││
│ │ As an admin, I want to see system health, ││
│ │ user activity, and pending approvals. ││
│ │ ││
│ │ 2. Manager dashboard (5 pts) ││
│ │ As a manager, I want to see team metrics, ││
│ │ sprint progress, and capacity. ││
│ │ ││
│ │ 3. Developer dashboard (3 pts) ││
│ │ As a developer, I want to see my assigned ││
│ │ tasks, recent activity, and blockers. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFIT: Each persona gets exactly what they need │
│ Can prioritize by user importance │
└─────────────────────────────────────────────────────────────┘
By Happy Path + Edge Cases
SPLITTING BY SCENARIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATTERN: Start Simple, Add Complexity │
│ │
│ ORIGINAL (13 points): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ As a customer, I want to purchase items so that ││
│ │ I can receive products. ││
│ │ ││
│ │ Includes: ││
│ │ • Add to cart ││
│ │ • Multiple payment methods ││
│ │ • Discount codes ││
│ │ • Failed payment handling ││
│ │ • Partial refunds ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SPLIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HAPPY PATH (ship first): ││
│ │ 1. Basic checkout with credit card (5 pts) ││
│ │ Single item, one payment method, success path ││
│ │ ││
│ │ ENHANCEMENTS: ││
│ │ 2. Add discount codes (3 pts) ││
│ │ Validate and apply discount ││
│ │ ││
│ │ 3. Multiple payment methods (3 pts) ││
│ │ Add PayPal, bank transfer ││
│ │ ││
│ │ EDGE CASES: ││
│ │ 4. Handle payment failures (3 pts) ││
│ │ Retry logic, error messaging ││
│ │ ││
│ │ 5. Process refunds (3 pts) ││
│ │ Full and partial refunds ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Can ship after story 1 - basic checkout works │
│ Each additional story adds capability │
└─────────────────────────────────────────────────────────────┘
By Data Variations
SPLITTING BY DATA TYPE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATTERN: Different Data, Same Feature │
│ │
│ ORIGINAL (13 points): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ As a user, I want to export my data so that ││
│ │ I can analyze it in other tools. ││
│ │ ││
│ │ Formats: CSV, Excel, PDF, JSON ││
│ │ Data: Orders, Users, Products, Analytics ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SPLIT BY FORMAT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Export to CSV (3 pts) ││
│ │ 2. Export to Excel (3 pts) ││
│ │ 3. Export to PDF (5 pts) - more complex ││
│ │ 4. Export to JSON (2 pts) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OR SPLIT BY DATA TYPE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Export orders (3 pts) ││
│ │ 2. Export users (2 pts) ││
│ │ 3. Export products (2 pts) ││
│ │ 4. Export analytics (5 pts) - more complex ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ START WITH: │
│ Most valuable data + most common format │
│ "Export orders to CSV" │
└─────────────────────────────────────────────────────────────┘
Maintaining Value
INVEST Criteria
ENSURING SPLIT STORIES ARE GOOD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EACH SPLIT MUST STILL MEET INVEST: │
│ │
│ I - INDEPENDENT │
│ Can be developed without other stories │
│ (some dependency OK, but not blocking) │
│ │
│ N - NEGOTIABLE │
│ Details can be discussed with team │
│ Not over-specified │
│ │
│ V - VALUABLE │
│ Delivers something useful to user │
│ Not just technical work │
│ │
│ E - ESTIMABLE │
│ Team can size it │
│ Not too vague │
│ │
│ S - SMALL │
│ Fits in a sprint │
│ Ideally 1-5 points │
│ │
│ T - TESTABLE │
│ Clear acceptance criteria │
│ Can verify it works │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AVOID: │
│ ❌ Technical tasks ("Set up database") │
│ ❌ Horizontal slices ("Build API layer") │
│ ❌ Layers ("Frontend for feature X") │
│ │
│ PREFER: │
│ ✅ Vertical slices that work end-to-end │
│ ✅ User-facing value in each story │
│ ✅ Could ship after any story │
└─────────────────────────────────────────────────────────────┘