User Story Splitting

Purpose

Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.

This is not arbitrary slicing—it's strategic decomposition that preserves user value while reducing complexity.

Key Concepts

The Story Splitting Framework

Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:

1. Workflow steps: Split along sequential steps in a user's journey
2. Business rule variations: Split by different rule scenarios (permissions, calculations, etc.)
3. Data variations: Split by different data types or inputs
4. Acceptance criteria complexity: Split when multiple "When" or "Then" statements exist
5. Major effort: Split by technical milestones or implementation phases
6. External dependencies: Split along dependency boundaries (APIs, third parties, etc.)
7. DevOps steps: Split by deployment or infrastructure requirements
8. Tiny Acts of Discovery (TADs): When none of the above apply, use small experiments to unpack unknowns

Why Split Stories?

• Faster feedback: Smaller stories ship sooner, allowing earlier validation
• Reduced risk: Less to build = less that can go wrong
• Better estimation: Small stories are easier to estimate accurately
• Maintain flow: Keeps work moving through the sprint without bottlenecks
• Testability: Smaller scope = easier to write and run tests

Anti-Patterns (What This Is NOT)

• Not horizontal slicing: Don't split into "front-end story" and "back-end story" (each story should deliver user value)
• Not task decomposition: Stories aren't tasks ("Set up database," "Write API")
• Not arbitrary chopping: Don't split "Add user management" into "Add user" and "Management" (meaningless)

When to Use This

• Story is too large for a single sprint
• Multiple "When" or "Then" statements in acceptance criteria
• Epic needs to be broken down into deliverable increments
• Team can't reach consensus on story size or scope
• Story has multiple personas or workflows bundled together

When NOT to Use This

• Story is already small and well-scoped (don't over-split)