User Stories: How to Write Them Well (With Examples and Splitting Patterns)
A user story is a short description of a need told from the user's perspective: As a <role>, I want <capability>, so that <benefit>. The format is famous; the point is routinely missed. A story is not a lightweight requirement document — it's a placeholder for a conversation, deliberately incomplete so the team discusses the need rather than mechanically implementing a spec.
The three Cs
- Card — the short written form; brevity is a feature.
- Conversation — where the real requirements emerge, in refinement and during the Sprint.
- Confirmation — acceptance criteria that let everyone agree what "works" means.
What good looks like: INVEST
- Independent — schedulable in any order, no hidden chains.
- Negotiable — details open for discussion, not contractually frozen.
- Valuable — delivers something a user or the business would notice.
- Estimable — understood well enough to size.
- Small — finishable well within a Sprint.
- Testable — you can tell when it's done.
Acceptance criteria that earn their keep
Keep them behavioural — what the system does, not how it's built. Given/When/Then reads well for flows:
Story: As a returning customer, I want to check out without re-entering my card details, so that repeat purchases are fast.
- Given a logged-in customer with a saved card, when they reach payment, then the saved card is offered as the default method.
- Given the saved card has expired, when they reach payment, then they are prompted to update it before paying.
- Card details are never displayed in full anywhere in the flow.
Three to six criteria is the sweet spot. Fifteen criteria means the story is really an epic, or the team is writing a spec and calling it a story.
Seven splitting patterns
Big stories hide risk. Split by:
- Workflow steps — checkout: pay first, then add invoicing, then gift options.
- Business rule variations — flat shipping first; weight-based rules later.
- Happy path vs edge cases — core flow now, failure handling as follow-ups.
- Input methods / platforms — web first, mobile next.
- Data variations — one currency, then multi-currency.
- CRUD breakdown — create and view before edit and delete.
- Spike then build — a timeboxed investigation when uncertainty blocks estimation.
Every slice should still deliver something observable — "the database layer" is a task, not a story.
Anti-patterns to avoid
- Fake roles — "As a developer, I want a new index…" Users don't want indexes; either find the real beneficiary or write it plainly as technical work.
- The novel — a story with ten paragraphs of prescriptive detail has already replaced the conversation it was meant to start.
- So-that theatre — a benefit clause that restates the feature ("…so that I can log in with SSO"). If the benefit is hollow, question the story.
- Story = task list — stories describe outcomes; the Developers own task decomposition.
Writing and splitting stories well is a core skill in Product Owner training, and Scrum Masters coach the practice daily — it features in the CSM course too. The CSPO guide shows where it sits in the full curriculum.
Frequently asked questions
Are user stories required by Scrum?
No — the Scrum Guide only says Product Backlog items. Stories are simply the most popular format because they keep the user in the sentence.
Who writes them?
Anyone may draft; the Product Owner stays accountable for content and order. The best stories are co-written in refinement.
How detailed should a story be before Sprint Planning?
Detailed enough to size and start confidently — understanding beats documentation; the rest emerges during the Sprint.