User stories were introduced as a deliberately lightweight alternative to heavyweight requirements documents. Two decades later they are the dominant way product work gets described in most organisations, and the lightweightness has become a liability — most user stories are bad. They under-specify, over-specify, or specify the wrong things. The cost shows up in clarification cycles during sprint planning, scope creep during implementation, and feature work that does not match what the requester actually wanted.
The Format Is Not the Problem
"As a [user], I want [capability] so that [outcome]" is a perfectly fine template. The problem is rarely the template — it is what gets written into it. A story that says "as a user, I want to be able to filter results so that I can find what I am looking for" passes the template test and tells the engineer effectively nothing. Better stories specify the user precisely (which user, in what context), the capability precisely (what kind of filter, on which fields), and the outcome precisely (what decision the user is trying to make).
Acceptance Criteria Are Where the Real Work Happens
A user story without acceptance criteria is not ready for sprint planning. The acceptance criteria are what define done — what the team has to demonstrate to call the story complete. Strong acceptance criteria are testable (you can write a check that passes or fails), they cover the happy path and at least the obvious edge cases, and they are written from the user perspective rather than the implementation perspective. Stories with thin acceptance criteria produce work that meets the literal interpretation and misses the actual intent.
INVEST Is Still the Right Quality Bar
- Independent — the story can be developed without depending on another story in the same sprint
- Negotiable — the implementation details are open for discussion; the outcome is fixed
- Valuable — there is a real user or business outcome, not just an internal task
- Estimable — the team has enough information to estimate effort with reasonable confidence
- Small — fits in a sprint with room for the unexpected; if it does not, split it
- Testable — there is a clear way to verify the story is complete
A useful sprint planning test: ask the team "what would we need to know to start work on this tomorrow morning?" If the answers are practical engineering questions (architecture, libraries, design choices), the story is ready. If the answers are product questions (what should this look like, who is this for, what happens in this scenario), the story is not. Sending unready stories to sprint planning produces ceremonial planning sessions and predictable scope explosions.
Splitting Big Stories Without Losing Meaning
Stories that are too large to fit in a sprint need to be split. The wrong way: split by technical layer ("backend story," "frontend story," "tests story") — each piece delivers no user value alone. The right way: split by user value — different user types, different scenarios, different acceptance criteria from the same parent. Each split produces a story that, if shipped alone, would be useful to some subset of users. The team can then sequence which slices to deliver first based on business value rather than technical convenience.
The Conversation Story Templates Cannot Replace
User stories were originally described as 'placeholders for a conversation,' and the conversation matters as much as the story. Stories written by a product manager and dropped into the backlog without team engagement consistently produce worse outcomes than stories developed collaboratively. Backlog refinement sessions where the team interrogates the story before sprint planning are the highest-leverage practice in modern product development. The story is the artefact; the shared understanding the conversation produces is what actually drives delivery.
When User Stories Are the Wrong Tool
User stories are the right tool for incremental product capabilities with identifiable users and outcomes. They are not the right tool for technical work without user-visible outcomes (infrastructure changes, migrations, refactors), regulatory or compliance requirements (which are obligations, not user wants), or large-scale design changes (which are decisions before they are stories). Forcing user story format on this work produces awkward stories that nobody finds useful. Use the right artefact for the work — task tickets, technical specs, design proposals — and reserve user stories for the work that actually fits.