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.
Liz Keogh, lunivore 
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
Thank you so much.I had a home work which asked me,how to evaluate scenario against a criteria and rank the best least.This has background of financial service scenario planning
Pingback: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria « antonymarcano.com
Pingback: Рубрика «Полезное чтиво». Выпуск 16 « XP Injection
A very clear explanation.
Dinosaurs like me define a scenario as a path through a use-case, with associated pre- and post-conditions and flows of information across the system boundary. That seems to be exactly the way in which you are using the term, except that you neatly avoid all the jargon 🙂
Pingback: User Story Acceptance « Tales from a Trading Desk
Interesting breakdown however i’d go so far to say that aspects of a systems behaviour are irrelevant to a stories acceptance criteria because the acceptance criteria are aligned to the outcome to be achieved by implementing that story; therefore, acceptance criteria are a list of ‘values’ the outcome will deliver to the user. How they are delivered i.e. how the system behaves is irrelevant and needs NOT to be defined when stating the problem and expected outcome because it inhibits solution innovation and turns the story into yet another ‘functional specification’ for the team.
Agree on the definition of the scenario because it’s the solution interaction and it’s integrity needs to tested.
It’s similar to the paradigm of don’t ask what customers want – watch what they do, listen for what they need to achieve, not what they think they need to do.
Maintaining a clear separation between outcome (problem) and solution (delivery) also helps to reinforce the paradigm of ‘take the problem to the team, they are the solution experts’
Hi Stephanie, if you look at the scenarios you’ll see that they’re declarative, rather than imperative. You could be performing them with a calculator or a pen and paper, and they’d still be the same. I tend to phrase both scenarios and acceptance criteria in terms of the capabilities of the system wherever possible, rather than its UI, and we consider that good BDD practice.
How the system behaves in terms of its UI isn’t irrelevant, because the developers eventually need to code it (and if you’ve ever got devs to design a UI you’ll know this isn’t a good idea!) I agree though that it should be a separate step, and the teams where the UX designer sits with the devs and collaborates iteratively over the UI tend to be more successful.
I also agree that it should be outside the scope of the scenarios and acceptance criteria. The behaviour isn’t irrelevant, but it’s phrased at a more abstract level than the UI.
Pingback: Acceptance Criteria vs. Acceptance Tests - Testing Excellence
Pingback: How To Give Constructive Feedback on User Stories
Thanks for this clear explanation. It is very useful and I can use it right away in my blog .your example you use nicely illustrates the abstraction level at which we should write acceptance criteria and scenarios. thanks once again http://www.mobileappstesting.com
Pingback: BDD Addict Newsletter March 2017 - Gáspár Nagy on software
Hi Liz,
Your acceptance criteria above relating to the pet shop refers to not being able to sell an animal below it’s suggested age, however, the acceptance criteria nor scenario states what the thresholds are. How would you define this? I would have usually thought to define this in the acceptance criteria.
Thanks
In this case I imagine that would probably be a configurable data table somewhere, created by experts. Given the variety of animals that pet shops could conceivably sell it wouldn’t make sense to me that it would be included in the ACs.
In similar situations, sure, you might define the thresholds there, maybe with a data table (which is still not the same as having actual concrete examples).
Pingback: Acceptance Criteria - KBP Media -
Pingback: BDD Addict Newsletter July 2017 - Gáspár Nagy on software
Pingback: Revisiting Testing vs Checking » Stories from a Software Tester
Thanks for a fantastic explanation, now I have to deal with my team and make them read this post.
Pingback: [Перевод] Введение в Example Mapping – CHEPA website
Very Interesting distinction between Scenarios and Acceptance Criteria. This post has been very useful for me as I work around Scenarios and Acceptance Criteria daily. Thank you very much, Liz.
I am learning but I find the words confusing .Do you have some more material so I can read further.My email is (email redacted by Liz) . Name Moyo.Studying Scenario planning
Hi Moyo, scenario planning is a bit different from what I’m doing with BDD, but I’m glad you’re finding this interesting. If you look for “BDD” in the categories on the sidebar you will find more on the topic of scenarios.
I think though that for scenario planning you may find Cynefin very interesting. This is the original article: https://hbr.org/2007/11/a-leaders-framework-for-decision-making – I hope that it may have been translated too. I also write about Cynefin so look at the categories there. Good luck with your studies!
Pingback: Acceptance Criteria
Pingback: Introducción al Mapeo de Ejemplos (Example Mapping) – Blog de NicoPaez