Scenario
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a living product specification.
A scenario describes one specific behaviour of a product: a starting state, something that happens, and what the product does in response. Scenarios aren't features, requirements, or test cases — they're statements of behaviour that anyone on the team can read and verify by using the product.
Each scenario has three parts: a Context (the situation), an Action (what triggers it), and an Outcome (what the product does). Scenarios are grouped into three categories: happy path (the expected flow), edge case (unusual but valid situations — often where support tickets originate), and error (what happens when things go wrong).
Together, scenarios build up a complete picture of a feature's behaviour. A feature with only happy path scenarios leaves your support team unprepared for everything else. Good specifications cover edge cases and errors too — the places customers actually run into problems.
Example
Related Terms
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.
A scenario that describes the expected, successful flow of a feature — what happens when everything goes right and the user stays on the main track.
A scenario that describes unusual but valid behaviour — the conditions at the edges of what the feature supports. Often the source of support tickets.
A scenario that describes what the product does when something goes wrong — invalid input, failed validations, blocked actions, or system-level failures.
Further Reading
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.