What Is a User Story? (And Why Scrum Doesn't Require One)

A user story is a short description of something a user wants, written from their point of view so the team discusses the need rather than a solution. It comes from Extreme Programming, not Scrum — the Scrum Guide never mentions user stories at all.

Almost every agile team writes user stories, and almost every one of them has argued about the correct way to do it. There's a reason those arguments never resolve: there is no official authority defining the format. Understanding where user stories actually come from settles most of the debate — and changes how you should use them.

The format, and what it's actually for

The template most teams use has three parts — who wants it, what they want, and why. Something like: as a returning customer, I want to reorder a previous purchase, so that I don't have to search for the items again.

The third clause is the one that earns its place. "As a customer I want a reorder button" is a solution someone has already chosen. "So that I don't have to search again" is the actual problem — and once it's written down, the team can ask whether a button is the best answer, or whether the search was the real issue.

Where user stories actually come from

This surprises most people, including many certified Scrum practitioners: user stories are not part of Scrum. They originated in Extreme Programming, the practice Kent Beck described in the late 1990s, where customers wrote short descriptions of the functions they wanted the system to perform.

This is why the format arguments never end: there's no rule to appeal to. It also means you're free to use something else when the template doesn't fit. A performance improvement, a compliance requirement or a database migration often reads better as a plain description than as a contorted "as a user, I want..." sentence. What matters is that the backlog item is clear enough to act on — see what a product backlog is.

INVEST: the closest thing to a quality standard

Since Scrum doesn't define story quality, teams borrowed a checklist from the XP world. Bill Wake articulated the INVEST criteria in 2003, and they remain the most useful test of whether a story is ready to work on.

Two of these carry most of the weight. If a story isn't estimable — usually sized in story points — the team doesn't understand it yet and needs a conversation rather than a better description. If it isn't testable, nobody will agree on whether it was delivered — which is where sprint reviews turn awkward.

Acceptance criteria: what "done" means for this story

A story is intentionally brief, so it needs something alongside it that says when it's complete. Acceptance criteria are the conditions that must be satisfied before the story can be considered finished — concrete, checkable statements rather than aspirations.

For the reorder example, they might be: the reorder option appears only for customers with a previous order; selecting it adds every still-available item to the basket; unavailable items are listed clearly rather than silently dropped. Each is something you can verify without discussion.

Three ways teams get this wrong

The failure modes are consistent enough to be worth naming, because each one is easy to spot in your own backlog.

• Stories as task tickets — "as a developer, I want to update the database schema" describes work, not a user need. It's a task, and calling it a story doesn't change that.
• Template theatre — forcing every item into the three-clause format, including ones where it adds nothing. The format serves the conversation; when it stops serving, drop it.
• Stories too large to finish — an item that can't be completed within a Sprint isn't ready to be selected, however well it's written. That's what refinement is for.

Who writes them?

In Scrum terms, the Product Owner is accountable for the Product Backlog and therefore for its items being clear — but that doesn't mean writing every one alone. In practice, stories are usually drafted collaboratively during refinement, with the Product Owner deciding what goes in and in what order. We cover that accountability in what a Product Owner actually does, and how the ordering decision works in what a product backlog is.

If any of this is new and you're heading toward these roles, the practical routes are in how to become a Product Owner and how to become a business analyst — the two jobs where writing these well is most of the work.