Acceptance Criteria vs. Scenarios
Some common confusion I’ve come across recently involves the difference between a Scenario and Acceptance Criteria.
I’ll start by defining these two things as I understand them.
- A scenario is an example of the system’s behavior from one or more users’ perspectives.
- Acceptance criteria are a set of rules which cover aspects of a system’s behavior, and from which scenarios can be derived.
Here’s a scenario from the pet shop I use in my BDD tutorials.
Given a rabbit called Fluffy who is 1 1/2 months old
When we try to sell Fluffy
Then we should be told Fluffy is too young.
This is an example of the kind of thing a pet shop employee might encounter in the till software. It’s quite specific, containing actual data, and illustrates our domain nicely. We can tell quite a lot from this: that pets have names, that there are rules around the sale of pets, the units in which we measure the age of young pets, etc.
We can’t tell, though, what age we would be allowed to sell the pets. Is it fixed? For all pets? Let’s look at something else:
Given a baby animal is younger than its recommended selling age
When we try to sell it
Then we should be told it's too young.
Despite the Given, When and Then, this is not a scenario. It’s acceptance criteria – a full specification of this aspect of behavior – phrased in scenario form. A lot of the time, I see people write criteria like this, then become confused when they can’t treat it like a real scenario – discussing it in detail, deriving further edge cases, automating it, etc.
Talking through scenarios is, for me, the most important aspect of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.
When we’re discussing the scenarios, it isn’t always necessary to write scenarios for all the acceptance criteria. As long as the acceptance criteria are clear enough to derive the relevant scenarios easily, I recommend leaving it as acceptance criteria until the point where it needs to be automated. You can tell if the scenarios can be derived in just a few seconds of conversation. You don’t need to write down everything.
It’s also possible to phrase acceptance criteria in other ways:
We should be prevented from selling animals younger than the recommended age.
Now you can talk through the scenarios, and see potential other criteria which you missed:
Customers should be encouraged to return when the animal is old enough to sell.
As you’re talking through the scenarios, the information we need for automation will emerge, and a better understanding of the domain spreads amongst the people involved in those discussions (usually a dev, BD and tester):
Given rabbits can't be sold before they're 2 months old
Given Fluffy the rabbit is 1 1/2 months old
When we try to sell Fluffy
Then we should be prompted to tell the customer, "This pet is too young. Please come back in 15 days to collect your pet."
By talking about both acceptance criteria and scenarios, asking why, and using scenarios to illustrate the criteria, we find out more about our domain. We can also automate them later on, where they’ll help to provide living documentation and act as regression tests.
There’s one other difference between a Scenario and Acceptance Criteria or even an Acceptance Test. You can ask your business stakeholders, “Can you give me a scenario where that happens?” or “Can you give me an example?” I’ve found this often draws out more useful discussions than, “Can you give me acceptance criteria for this?” or “Can you help me work out how to test this?”
The language of BDD, and particularly its vocabulary, provide a ubiquitous language for analysis and development.
Now we’re talking.
6 Responses to “Acceptance Criteria vs. Scenarios”
Hi Liz,
Nice distinction between ‘criteria’ and ’scenario’. It’s good to be clear about what you mean when you use these terms. I have a different understanding of the terms, but rather than define/redefine “Acceptance Criteria” I would sooner avoid the term altogether.
One of the things I like about the history of BDD is the choice of language. Specifically, choosing words that people can relate to but are not overloaded within a domain – allowing us to side-step distracting debates about definitions of commonly used terms and crack on with effectively communicating.
I think you’ve captured this excellently where you say:
/“Can you give me a scenario where that happens?” or “Can you give me an example?” I’ve found this often draws out more useful discussions than, “Can you give me acceptance criteria for this?” or “Can you help me work out how to test this?”/
So, what I think is important is not how we define or re-define these terms but which terms or questions are most effective at yielding the class of answer we need. I have seen much variation in the class of answers people give when asked for criteria. I have, like you, seen more people give the class of answer I need when asked for an ‘example’.
In this regard, my experience has been that ‘example’ is more effective than ’scenario’ which is, in turn, more effective than ‘criteria’.
For a language to become ubiquitous, growing an understanding of it should be easy. In my experience, having to tear-down someone’s existing definitions (only a limited articulation of their mental model) in order to replace them with new ones adds friction to that process. Using alternative jargon-free terms that people can almost immediately relate to in a (mostly) common way increases the chances that we find our way to a common understanding, relatively quickly.
That aside, I think starting where that person happens to be – even if the easiest way for them to start articulating their current understanding is in the form of a rule or solution – is ok. Through conversations exploring the examples and by iteratively demonstrating the product of our current understanding, we’ll all arrive at the right place in the end.
In short, I hope readers primarily take away the usefulness of terms like ‘example’ in getting the information we need as the key message of your post.
Best regards,
Antony
A very nice distinction between ‘criteria’ and ’scenario’. We many a times do confuse overself by using these words interchangibly
Thanks for this clear explanation. It is very useful and I can use it right away in my project.The example you use nicely illustrates the abstraction level at which we should write acceptance criteria and scenarios, something we have been struggling with.
liked it. diff between acceptance criteria and scenario is mentioned well
[...] that article, Rachel distinguishes between acceptance criteria and example scenarios by reference to Liz Keogh’s blog post on the subject of “Acceptance Criteria vs. Scenarios&…: “where she explains that acceptance criteria are general rules covering system behaviour [...]
[...] Acceptance Criteria vs. Scenarios – отличия приемочного критерия от сценария и приемочного теста [...]