User stories, from format to splitting to acceptance criteria.

A user story is a short description of a change, told from the perspective of the person who wants it. Not a specification. Not a contract. A placeholder for a conversation the team will have when the work gets close. Atlassian's guide to user stories describes them as informal, general explanations of a feature written from the end user's point of view, and that word informal is doing real work. The informality is a feature. It stops teams from pretending they know everything up front.

The story exists to keep three things attached that most delivery processes tear apart: the person who wants something, the thing they want, and the reason they want it. When those three travel together, an engineer three weeks later can make a sensible judgement call without a meeting. When they separate, you get software that technically matches the ticket and helps nobody.

One more thing worth being blunt about. Stories are a tool from Extreme Programming that agile teams adopted widely. The Scrum Guide never mentions them. If the format is not serving a particular piece of work, you are allowed to not use it. More on that in the comparison section below.

The canonical shape has three clauses:

Each clause has a job. The role clause forces you to name a real person with real context, and "user" is not a real person. The want clause states a capability, not a solution, which keeps design options open. The so-that clause is the one teams mumble through, and it is the most important of the three: it is the only place the story justifies its own existence. A story whose so-that clause you cannot finish honestly is a story you should question.

When to break the format: when it adds ceremony without information. Bugs need reproduction steps, not personas. Technical enablers deserve to be honest tasks rather than "As a developer, I want to refactor the billing module". And when context matters more than identity, the job story format (covered below) swaps the persona for a situation. The format is scaffolding. The attached who, what and why is the actual requirement.

Ron Jeffries, one of the founders of Extreme Programming, described a user story as three Cs, and the framing has outlived almost every other piece of agile vocabulary because it describes what stories are for rather than what they look like.

Acceptance criteria are the Confirmation in the 3Cs: the concrete checks that make done a fact instead of an opinion. The most reliable format is Gherkin, the Given/When/Then structure borrowed from behaviour-driven development, written as a numbered list so individual scenarios can be referenced in review and in test names.

Each clause earns its place. Given pins down the state, which is where most testing ambiguity hides: signed in or not, data present or empty, feature flag on or off. When names exactly one action, and if you need "and then they also" you probably have two scenarios. Then must be observable from outside the system. "Then the record is updated correctly" is not observable. "Then the confirmation page shows the new address" is.

Three habits separate useful criteria from decorative ones:

• Cover the unhappy paths. A story with only a happy-path scenario has not been thought through. The empty state, the permission failure and the invalid input are where the real engineering effort lives, so they belong in the criteria.
• Number them. "AC 3 fails on Safari" is a useful bug report. "The acceptance criteria are not met" is a shrug. Numbers also map cleanly onto automated test names.
• Keep them free of implementation. Criteria describe behaviour at the boundary of the system. The moment a scenario names a database table or a component, it will break the first time the implementation changes, and the team will learn to ignore criteria.

If a story arrives without criteria and you want a starting point faster than a blank page, the free acceptance criteria generator drafts numbered Gherkin scenarios from a pasted story, which you then edit in the conversation rather than accept wholesale.

Almost no story is born at a keyboard. It is born in a refinement session, a discovery call or a support escalation, as a sentence someone says out loud. The gap between that sentence and a well-formed story in the backlog is where most teams leak requirements: someone scribbles a note, the note loses the context, and three days later a story appears that says half of what was meant.

Everything in this guide is a manual discipline for closing that gap. There is also a tooling answer. Backlog.cloud listens to the meeting, or reads the transcript afterwards, and drafts stories in the shape this guide describes: specific personas, honest so-that clauses, numbered Gherkin criteria, each item anchored to the verbatim quote it came from. The drafts land in a review queue where a human applies exactly the judgement described above, then pushes the survivors to the backlog. The AI user story generator page shows the output shape in detail, and transcript to user stories covers the paste-a-transcript route if no bot was on the call.

The point is not that a machine writes your stories. It is that the raw material, the actual words people said, stops evaporating between the meeting and the backlog. What a production-ready generated story looks like, field by field, is documented on the user stories artefact page.