User Story
A short statement of a feature from the perspective of the user, typically following the format “As a [role], I want to [action], so that [benefit].” A planning artefact, not a behaviour spec.
User stories are a planning tool. They were designed to express intent — who wants what, and why — in a format short enough to fit on an index card and concrete enough to drive a sprint conversation. Done well, they help a team agree on what they're trying to build before they build it.
Where user stories struggle is everything that comes after the conversation. A user story tells you a feature was planned. It doesn't tell you what the feature actually does after it ships, how edge cases are handled, what error messages appear, or what changed in last Tuesday's release. None of those questions — the questions PMs, support, and stakeholders ask most — can be answered by re-reading the original user story.
A scenario is the complement to a user story. The user story captured the planning conversation; the scenario captures the resulting behaviour. Scenarios are written in Context/Action/Outcome format and updated automatically as the code changes. User stories sit in the backlog; scenarios sit in the spec. Both are useful, for different parts of the lifecycle.
Related Terms
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a living product specification.
A written description of how a product behaves — feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
A structured format for describing product behaviour. Precise enough to be unambiguous, plain enough for anyone on the team to read — without the machine-oriented syntax of BDD.
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.