Learning Objectives
By the end of this lesson you will be able to:
- Explain why large User Stories fail in Scrum
- Apply at least five of the nine common slicing patterns
- Distinguish between a good slice and a bad split
- Identify which slicing pattern applies to a given large story
Why Large Stories Fail
A 21-point story in a 40-point sprint is a liability. It consumes more than half the sprint's capacity, and if it doesn't complete, the entire sprint goal is at risk. Large stories also:
- Take multiple days to start showing progress (invisible work)
- Are harder to estimate accurately (complexity compounds)
- Have multiple people waiting on single pieces
- Are more likely to reveal mid-work surprises that weren't visible upfront
The Scrum principle is that every story should be small enough to complete in a single sprint — ideally, in 2-3 days. Stories that can't meet that bar need to be sliced.
Good Slice vs Bad Split
This distinction matters:
A good slice is independently deliverable and provides value on its own. The user can do something with it. It could ship to production without the other slices.
A bad split is a technical partition that creates dependencies between pieces. "Backend API" and "Frontend UI" as separate stories sound like slices but aren't — neither is independently testable or shippable.
The test: "Could this slice go to production alone, and would users find it useful?" If yes, it's a slice. If no, it's a split.
The Nine Slicing Patterns
Pattern 1: Workflow Steps
Take a multi-step process and implement one step at a time.
Example: "User can complete the checkout process" →
- Slice A: User can add items to cart
- Slice B: User can enter shipping address
- Slice C: User can enter payment details and confirm
Pattern 2: Happy Path / Unhappy Path
Implement the success case first, then add error handling.
Example: "User can upload a profile photo" →
- Slice A: User can upload a valid JPEG/PNG photo (happy path)
- Slice B: System handles invalid file types, oversized files, and network errors
Pattern 3: CRUD Operations
Split by create, read, update, delete — deliver each separately.
Example: "Admin can manage products" →
- Slice A: Admin can view product list
- Slice B: Admin can create a new product
- Slice C: Admin can edit an existing product
- Slice D: Admin can delete a product
Pattern 4: Business Rule Variations
Implement the common case, then add the exceptions.
Example: "System calculates shipping cost" →
- Slice A: Standard domestic shipping rate
- Slice B: Express shipping option
- Slice C: International shipping rates
Pattern 5: Simple / Complex
Deliver a simplified version first, then add complexity.
Example: "User can search for products" →
- Slice A: Search by product name (exact match)
- Slice B: Fuzzy search with typo tolerance
- Slice C: Filtered search by category, price, rating
Pattern 6: Defer Performance
Build the correct behavior first, optimize later.
Example: "System generates monthly report" →
- Slice A: Report generates correctly (even if it takes 30 seconds)
- Slice B: Report generation optimized to under 3 seconds
Pattern 7: Roles / User Types
Implement for one user type, then extend to others.
Example: "Users can export data" →
- Slice A: Export available for Admin users
- Slice B: Export available for Standard users with permission restrictions
Pattern 8: Data Scope
Implement for a subset of data, then expand.
Example: "Migrate user data from legacy system" →
- Slice A: Migrate data for 100 pilot users
- Slice B: Migrate remaining 50,000 users in batches
Pattern 9: Interface / API First
Build the interface or contract, then implement the full logic.
Example: "Integrate with payment provider" →
- Slice A: Mock integration with contract tests passing
- Slice B: Real integration with payment provider
Applying Slicing in Practice
When a story is too large, ask: "Which pattern applies here?"
The fastest way to identify the right pattern is to ask the question: "What's the smallest thing we could build that would still provide value to a real user?"
If the answer involves a user action, it's probably Workflow Steps or CRUD.
If the answer involves risk, it's probably Happy Path / Unhappy Path.
If the answer involves scale, it's probably Data Scope or Defer Performance.
Pro Tip: After slicing, verify that each slice could be deployed to production independently. If slices require each other to work, you've made splits, not slices.
Summary
Story slicing is the most powerful technique for making sprints predictable. Small stories flow faster, complete more often, and give teams the feedback they need to improve. The nine patterns cover almost every large story you'll encounter. The discipline of asking "which pattern applies?" before estimating transforms a team's ability to plan and deliver consistently.