the Acceptance Criteria consist of a collection of Scenario allow us to determine when we are done, The most important aspect of a story is the language in which it is written.
The golden rule is that the Story should be written in the language of the Role, that is to say the beneficiary of the feature.
If the Story represents a business feature, it should be written in business terms with the aid of a business analyst.
If the story describes a technical requirement, such as resilience or scalability (sometimes called “non-functional” requirements), it should be presented in the appropriate technical language.
Acceptance Criteria specify, as a collection of Scenario, what needs to be achieved if the Behavior of the Feature is to be considered finished.
A Scenario:
Some Behavior that can be automatically verified once the Story (or some part of it) is delivered.
The Scenario sets up the world in a known state (or in a way that will behave deterministically) and executes a sequence of one or more Events resulting in one or more verifiable Outcomes.
We commonly implement these scenarios, as FIT fixtures, Selenium tests or programmatically as code, but the technology is less important than the concept here, the aim of these verifiable scenarios is to define what a successful outcome looks like.
This use of Scenarios gives us two immediate returns.
- They form the basis for our estimates, leading to more consistent estimates than story-level estimations.
- They show when a story is trying to do “too much”.
If there are more than a handful of scenarios (five or six), it suggests that the story should be split into several smaller stories, each providing independent benefit, and each consisting of a subset of the scenarios.
Boundary or exception cases are good examples of this: sets of boundary scenarios might clump together to describe common business cases, and some of these clusters will be deemed more important than others. Smaller stories means finer-grained control over prioritization, finer grained visibility of progress and reduced exposure to technical risk.
Scenario structure:
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…