User stories and acceptance criteria engineers can build from

Most user stories are written to be read once in a planning meeting and then ignored. The ones worth writing are the ones an engineer can build from without a meeting, and a tester can check without asking what you meant. Every case study on this site includes the actual backlog, so rather than invent examples, I'll use those.

The story is the "why", the criteria are the "done"

The story format is familiar: as a [person], I want [something], so that [outcome]. What people forget is that the story is the reason for the requirement, and a different thing from the requirement itself. Here is one from Scrutas: "As a site operator, I want to authorize deeper testing with a header, not credentials, so legal and security can sign off without friction." An engineer reading that knows what to build and, more usefully, knows what not to build. A login form would satisfy the words "authorize deeper testing" and completely miss the point.

The acceptance criteria are where the story becomes checkable. For that story the criterion was: "Cryptographic domain-verification header, single-use, 72-hour expiry, hash-only storage, gates Stage 2." Every clause is testable. Someone can try to reuse the header and confirm it fails. Someone can check the database and confirm no plaintext token is stored. If a tester can't tell whether it passed, you haven't written a criterion yet.

Name a real person

"As a user" is the most common opening line and the least useful. Users don't exist; store managers, agency owners, and council engineers do. ShiftFlow's stories say "as a store manager." Squint's say "as an agency owner" and, separately, "as an individual site owner," because the two want different things from the same audit. PavIQ's say "as a council engineer" and "as a fleet operator," and the split matters because one is the buyer and the other is hosting the hardware for free. When the person in the story is specific, the acceptance criteria almost write themselves, because you can picture what they would check.

MoSCoW, used honestly

We tag every story Must, Should, Could, or Won't. The trick is that Must has to mean "the product does not ship without this," not "I care about this." On ShiftFlow, generating a compliant draft roster was a Must. A manager-facing analytics dashboard was a Could, and it still is. On Squint, white-labelled reports were a Should, because agencies asked for them but the product worked without them, and bulk audit mode was a Could. If more than about a third of a backlog is Must, the prioritization hasn't happened yet.

Won't is the most valuable tag and the least used. Writing down what the product deliberately will not do, and why, is the thing that stops the same argument happening every sprint. GridSentinel's theft detection is a documented Won't for the first product, with the physics reason attached. That one line has saved several conversations.

Numbers over adjectives

"Fast," "easy," and "secure" are not criteria. "Stage 1 recon returns three to five findings in under three minutes with zero authentication" is. "Detect and classify road defects at 200 Hz with Minor, Moderate, Severe grading" is. "Buffer up to 72 hours of data offline" is. When a criterion has a number in it, the conversation with engineering shifts from "is it done" to "does it hit the number," which is a much better conversation to have. When you don't know the number yet, say so in the criterion, and make finding it a task.

The template

Each story on our backlogs is five lines: an ID, the story in as-I-want-so-that form, the MoSCoW tag, the acceptance criteria as a short list with numbers where they exist, and one line on what evidence from discovery justifies it. That last line is unusual and I'd argue it is the most important. "Because Ashmita viewed twenty rooms in six months" is a better reason to build the Property Trust Score than "because it seemed like a good idea," and when the story gets challenged in three months, the evidence is right there.

The Scrutas, ShiftFlow, and Squint case studies each carry their full backlog in this format. Steal the structure. The stories themselves are yours to write, and they'll be better if you've done the interviews first.

Sources and further reading

• Scrutas case study. Six user stories and the requirements written as acceptance criteria.
• ShiftFlow case study. The backlog behind a product in production.
• Squint case study. Stories for a two-sided product.