Story Splitting
Workflow steps, happy/unhappy paths, thin vertical slices, and the SPIDR framework
Story splitting patterns
- By workflow step: view → create → edit → delete — each action is one story
- By path: happy path (success) first, then unhappy paths (errors, edge cases)
- Thin vertical slice: one narrow use case, full-stack, independently deliverable
- Split signal: "and" in the goal — "I want to create, edit, and delete" → 3 stories
- SPIDR: Spike, Paths, Interfaces, Data, Rules — five splitting patterns
Question 0 of 5
A team has a story: "As a user, I want to manage my profile so that I can keep my information up to date." This story is too large. Which splitting pattern is most appropriate?
Split by workflow step — each profile management action becomes its own story. Workflow step splitting:
- Each step is independently deliverable and testable
- The team can ship "view profile" in sprint 1 before building "edit profile"
- Stakeholders get feedback earlier
What does "splitting by happy path vs. unhappy path" mean in story splitting?
Happy path = successful flow; Unhappy path = error states and edge cases. Example for a payment feature:
- Story 1 (happy path): "As a user, I want to pay with a saved card so that I can complete my purchase quickly." — covers successful payment only
- Story 2 (unhappy paths): "As a user, I want to see helpful error messages when payment fails so that I know what to do next." — covers card declined, expired card, insufficient funds, network timeout
Which user story correctly represents a "thin vertical slice" of a larger feature?
Exact-name-match only — deliverable, testable, full-stack slice. What makes a good thin vertical slice:
- ✅ Deliverable: the user can actually use it — type a name, see results
- ✅ Testable: one clear acceptance scenario
- ✅ Full-stack: includes frontend input, backend search, database query, and results display
- ✅ Intentionally constrained: "no autocomplete, no fuzzy match" — explicitly scopes it thin
The SPIDR framework for story splitting suggests 5 patterns. Which pairing correctly describes two of them?
Spike = research/exploration story; Path = split by workflow steps. SPIDR framework:
- S — Spike: a time-boxed research task to reduce uncertainty ("Spike: investigate third-party payment providers — 2 days")
- P — Paths: split by different user workflows through the same feature
- I — Interfaces: split by input/output interface (mobile vs. desktop, API vs. UI)
- D — Data: split by data subset (first support one currency, then multiple)
- R — Rules: split by business rules (first support basic validation, then complex rules)
A story says: "As an admin, I want to manage users — including creating, editing, deactivating, and deleting users — so that I can control access." How many stories should this become?
Four stories — one per CRUD operation. Why split by operation:
- Create user → different UI (form), validation rules, backend endpoint
- Edit user → different UI (pre-filled form), partial update endpoint
- Deactivate user → soft delete, session invalidation
- Delete user → hard delete, cascade rules, GDPR data deletion