Writing User Stories and Acceptance Criteria That Work
Key takeaway
A story is a placeholder for a conversation plus a list of testable acceptance criteria. If the criteria can't be verified objectively — by a person or a test — the story isn't ready, and the team will discover the disagreement during review instead of before development.
User stories get criticised as ceremony, usually because they've been reduced to a naming convention for tasks. The format earns its place only when the conversation and the acceptance criteria come with it.
The story itself
- State who it's for, what they want to do, and why it matters. The why is the part that lets a developer make a sensible decision when the description is ambiguous.
- Write from the user's perspective, not the system's. "Add a column to the orders table" is a task; "see which orders are awaiting approval" is a story.
- Keep it small enough to finish within a few days. Large stories hide uncertainty and always finish late.
- It's a reminder to have a conversation, not a specification handed over a wall.
Acceptance criteria do the real work
- Each criterion must be objectively verifiable: given a situation, when something happens, then this result. No adjectives.
- Cover the unhappy paths — invalid input, missing permission, the external service being down. These are where the estimate actually lives.
- Include the non-functional expectations that apply: performance, permissions, audit, accessibility.
- Say explicitly what's out of scope, because otherwise it gets built or argued about.
- Write them before the work starts, with the tester in the room.
Splitting stories that are too big
- By workflow step — deliver the main path first, then the variations.
- By rule — implement the simple case, then the exceptions, each as its own story.
- By data type or user role, where each has meaningfully different handling.
- By interface: a functional version first, the richer interaction later.
- Never split by technical layer. A story delivering only the database change delivers nothing demonstrable.
Ready and done
Agree a definition of ready — criteria written, dependencies identified, designs available — and refuse to start stories that don't meet it. Agree a definition of done that includes tested, reviewed, documented where needed, and deployable. Those two agreements prevent more delivery problems than any estimation technique.