METHODOLOGY

User Story

A short description of a feature told from the user's point of view, in the form 'As a [role], I want [goal], so that [benefit]', used to capture intent rather than a technical spec.

Last reviewed: 2026-06-02 byKevin Riedl wiki β†—

A user story captures a piece of value from the perspective of the person who wants it, usually in the format “As a [role], I want [goal], so that [benefit]”. The format is not bureaucracy for its own sake. The “as a” forces you to name who actually wants this, and the “so that” forces you to state why, which is the part teams skip and then build the wrong thing. A story is a placeholder for a conversation, not a contract.

Good stories tend to satisfy the INVEST criteria: Independent (can be built on its own), Negotiable (the details are open until you discuss them), Valuable (delivers something a user or buyer cares about), Estimable (the team can size it), Small (fits inside an iteration), and Testable (you can tell when it is done). The last two are where most stories fall apart: too big to finish, or written so vaguely that nobody can say what “done” means.

Acceptance criteria are how a story becomes testable. They are the concrete conditions that must hold for the story to be accepted, written before the work starts. “As a user I want to reset my password” is an intention. The acceptance criteria (a reset link expires after an hour, an invalid token shows a clear error, a successful reset logs the user in) are what the team actually builds and tests against.

The common anti-pattern is the story that is a task in disguise. “As a developer I want to add an index to the orders table” has the user-story costume on, but there is no user and no benefit, just an engineering task wearing a hat. That is fine to track, but it is not a user story, and dressing technical tasks as stories quietly erases the user perspective the format exists to protect.

// FAQ

FAQs

FAQs

A short description of a feature from the user’s point of view, usually ‘As a [role], I want [goal], so that [benefit]’. It captures who wants something and why, and acts as a placeholder for a conversation rather than a full technical specification.
A checklist for a good story: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Most stories fail on Small (too big to finish in an iteration) or Testable (too vague to define done). The criteria are a quick way to catch stories that will cause trouble before the team commits to them.
When it is a technical task in disguise. ‘As a developer I want to add a database index’ has no real user and no benefit, just an engineering task in a costume. Tracking such work is fine, but calling it a user story erases the user perspective the format exists to protect, which defeats the point.