Scenarios are not Acceptance Criteria

November 2012

"That's all very well, but how do I know that it works?"

"What will that actually look like on screen?"

It can be hard to nail down a feature file. Some people like to argue over the wording of the preamble and jump into the scenario writing (much) later. Some prefer to get on with writing concrete examples to help jumpstart their thinking, and frame the story with the acceptance criteria later.

"So what's the point of this feature again?"

Whichever way we approach writing our feature files, it’s important that we iterate over our wording. Let’s not neglect either our acceptance criteria, or scenarios detailing concrete example behaviour. Without both, we’re making it hard for our developers to implement a feature, and making it hard for us to understand its purpose a few months down the line.

"Can you give me an example of that?"

It’s very easy to conflate the concept of scenarios with acceptance criteria: they aren’t the same thing. Scenarios are concrete examples of acceptance critera: they help flesh out and explore complex criteria, and ground them in reality. Without concrete examples it can be hard to get a handle on where to start when implementing a feature, and it’s difficult to wrap our minds around what needs to be done.

Lack of acceptance criteria: hesitation and confusion

Here’s a feature without acceptance criteria:

    Feature: Relating two people

    Scenario:
      Given a person called Joe
      And a person called Bob
      When I set Joe to be the father of Bob
      Then their relationship is recorded in the system

When we skip the acceptance criteria and jump straight into examples, we lose context. It’s hard to see how and why this feature exists, and who is using it?

Example scenarios aren’t good at describing design and user experience constraints on a feature. Developers will be tempted to rush straight through the implementation without paying attention to the detail. They’re also no good at communicating the need for other edge cases. Is there something else that we’ve missed here? What about distinguising between biological and adoptive parents, for instance? Or checks for age to ensure the father could be old enough to have children?

Lack of concrete example scenarios: haziness and obfuscation

We might be tempted to shoe-horn all that information into the scenario:

    Scenario: Relating two people
      Given a father and two children
      When I relate them either at adoptive or biological parents
      Then the relationship should be recorded
      And the sibling relationships should be worked out
      And we are warned if the father appears too young to have children
      But only if the relationship is biological

This isn’t a real scenario any more. We’re trying to describe several different things in one place. It could be implemented as several different scenarios joined together, but by itself the lack of concreteness means that we can’t easily reason about it, and it’s also nigh on impossible to automate without skipping some of the intent. Using ‘Given’, ‘When’ and ‘Then’ does not automatically make something a concrete example - all this information belongs in the preamble.

Combining acceptance criteria with real examples

Let’s try and combine both these techniques:

    Feature: Relating two people
      As Robert the royal historian, I want to show parent/child relationships
      in my family history system so that I can track royal lineage over many centuries.

      * I should be able to relate people as parent and child very simply and quickly
      * Sibling relationships can be automatically worked out
      * Each person can have biological parents, and adoptive parents
      * Ensure we warn our historian if the father is too young

    Scenario: Relate Joe and Bob as father and son

    Scenario: Bob and Elaine are siblings as Joe is father of both
      Given a person called Joe
      And a person called Bob
      And a person called Elaine
      When I set Joe to be the father of Bob
      And I set Joe to be the father of Elaine
      Then Bob and Elaine are shown as brother and sister

    Scenario: Bill is the adopted father of Elaine and Bob
    Scenario: Charlie is too young to be the father of Joe

Have a look at the acceptance criteria as listed in the preamble. They state both the reason for the story and they flesh out some more of the thinking. You can often leave the feature like this up until the point I want to work it, with criteria in bullet form. If the feature is complex and there’s a danger information will be lost, I’d recommend writing down examples during the planning of the story in order to properly capture the behaviour (like I’ve done here with the second scenario), but you don’t need to do this for every scenario until you come to automate it.

Summary

Think back on what you have just read. This post would have been hard to understand without the two examples above. Without concrete examples, it’s very easy to gloss over content.

Alternatively, if this post had just consisted of the two features above, followed by “Don’t do this! Any comments?”, our natural reaction would have been one of confusion. Don’t do what exactly? And what exactly should we do instead?

Just like a blog post without an example, or a teaching workshop without a practical element, if there’s no concrete example then acceptance criteria can lead to wishy-washing thinking. Similarly, if we just sit down and start working on something concrete without any clear context, we’ll struggle to see the reasons for doing it and we’ll miss edge cases. When you have both, that’s when you know you’ll understand.

Personally, I tend to the second error: because I can read code, I sometimes fall into the trap of not making my examples concrete enough. Which of these two do you more tend towards?

Postscript

For more, see Liz Keogh’s post on this topic from last year. For a slightly different point of view, check out Antony Marcano’s thoughts on scenario oriented acceptance criteria. Antony argues for using scenario titles as our list of criteria. I find it helpful to keep Scenario titles and Acceptance Criteria separate, as I don’t think there is always a clear mapping between the two. One is an evolution of the other, and it’s useful even when the scenario titles are written to keep the Acceptance Criteria around for context. What do you think?

BlueSky

Extreme YAGNI: How BDD nails your prototyping stage

May 2016

prototyping

Sometimes people don’t see the value in the BDD process. They contend that the BDD ceremonies are a waste of time, and get in the way of delivering real features to customers. Others cannot see how to apply BDD to their project, as no-one knowns exactly what the project will look like yet. As they’re only in the prototyping stage, by the time a feature file is written and made executable, it’s already out of date.

I don’t agree with this. If our process is set up right, we can prototype using just as effectively and retain the collaboration benefits that BDD gives us.

You Ain’t Gonna Need It

One of the biggest wins that Test-driven Development (TDD) gives us is the principle of YAGNI - “You Ain’t Gonna Need It”. It’s very tempting when writing code to go off on a tangent and produce a beautiful structured work of art that has zero practical use. TDD stops us doing this by forcing us only to write code that a test requires. Even some experts who don’t practice or encourage TDD often espouse the power of writing the calling code first in order to achieve much the same effect.

BDD gives us the same YAGNI win: but at a level higher than TDD. With the BDD cycle we’re adding thin slices of customer observable behaviour to our systems. If we can only write the code thats directly used by the business, then in theory we should be cutting down on wasteful development time.

However, there’s a snag here. if we’re prototyping, we don’t know whether this feature will make it into the final product. We still need to give feedback to our product team, so we need to build something. If the feature is complex, it might take a while to build it, and the feature might never get used. Why bother going through the process of specifying the feature using BDD and Cucumber features?

Happily, we can take YAGNI a level further to help us out.

Extreme YAGNI

Often in TDD, and especially when teaching it, I will encourage people to take shortcuts that might seem silly in their production code. For example, when writing a simple supermarket checkout class in Javascript, we might start with a test like this:

    var checkout = new Checkout();
    expect(checkout.total()).toEqual(0);

Our test defines our supermarket checkout to have a total of zero on creation. One simple way to make this work would be to define the following class:

    var Checkout = function() {
      this.total = function() {
        return 0;
      };
    }

You might think that’s cheating, and many people define a member variable for total, set it to 0 in the constructor, and miss this step out entirely. There is however an important principle at stake here. The code we have does exactly what the test requires it too. We may not need a local variable to store total at all.

Here’s the secret: we can practice this “extreme YAGNI” at the level of our features, too. If there’s a quick way to make our feature files work, then there’s nothing to stop us taking as many shortcuts as we can to get things working quickly.

For example, if we’re testing the user interface of our system via Cucumber features, one fast way to ensure things are working is to hard code the values in the user interface and not implement the back end behaviour too early. Why not make key pages static in your application, or hard code a few cases so your business gets the rough idea?

Again, you might think that’s cheating, but your features pass, so you’ve delivered what’s been asked for. You’ve spent the time thrashing out the story in a 3 amigos meeting, so you gain the benefits of deliberately discovering your software. You’re giving your colleagues real insight to guide the next set of stories, rather than vague guessing up front. Our UX and design colleagues now have important feedback through a working deployed system very quickly, and quick feedback through working software is a core component of the agile manifesto.

By putting off implementing the whole feature until later, we can use BDD to help us navigate the “chaotic” Cynefin space rather than just the “complicated” space. This in theory makes BDD twice as useful to our business.

Fast, fluid BDD

This all assumes that we have a fast, fluid BDD process, with close collaboration built in. If it takes a week to coordinate everyone for the next feature file, then the temptation is to have a long meeting and go through too many features, without a chance to pause, prototype, deliver and learn from working software. Maybe it’s time to re-organise those desks and sit all the members of your team together, or clean up your remote working practices, or block out time each day for 3 amigo sessions. You’ll be suprised how much small changes speed your team up.

Why BDD works solo, and why that matters for everyone

August 2014

“The monotony and solitude of a quiet life stimulates the creative mind.”

– Albert Einstein

It’s possible to play chess and many other games completely solo, without anyone else to play against.

solo chess

Incredibly, our minds are able to take on the role of both players in a competitive match. Our brains allow us to place ourselves in the opposing player’s shoes. Even more impressively, we are able to hide certain information from our own decision making process – such as what we’re planning to do next turn. We can analyse this incomplete set of information and play a move based solely on that, even if it’s sub-optimal.

BDD can be done solo

Using Behaviour-driven Development (BDD) on our own is much the same as playing a game against ourselves.

Instead of playing the opposing role, we take on the role of the stakeholder. We put ourselves in the shoes of the person paying for or commissioning the project. Because the BDD practice of writing gherkin-style features forces us to think in plain English, we jettison the role of programmer for a moment, and drift in the non-technical solution thought-space.

Why is this important? It’s a valuable exercise for a couple of reasons:

We gain a fresh perspective on what we are doing. By taking our heads out of the code and putting ourselves into the role of the stakeholder, we are able to see the wood for the trees and get perspective on the code we’re writing right now. It might be interesting code to write, but does it matter?
We gain a fresh perspective on the stresses of others. Every developer should take the opportunity to be a stakeholder once in a while. It’s very helpful to see what life it like on the other side of the estimation table. If all the members on a team are able empathise with the constraints and pressures our colleagues from different disciplines have, our team will run much more smoothly.

BDD solo is why BDD matters in the first place

Sometimes we confuse the concepts behind BDD with the tools used to practice BDD, like 3 amigo meetings, story breakdown and Cucumber.

BDD isn’t about the tools we use, it’s about the communication in the team. It’s about having the right conversations at the right times, hammering things out together, airing and refining thoughts and ideas, beating out ambiguity and forging common goals. This is why it matters.

If it was just about the tools, BDD would have been lost in the noise years ago, and BDD solo would be an expensive overhead. Why add another layer of tool complexity if it’s just us?

However, because BDD is about the concepts, not the tools, BDD works just fine solo: the process of deliberately stepping outside our developer role and thinking through our project from a product perspective gains us insight and understanding. This works no matter what tools, languages, frameworks or practices we may prefer.

When we’re solo, we dispense with a lot of the tools we don’t need. We don’t need to schedule a 3 amigo meeting with ourselves, for example. We’re left with a very pure form of BDD, set free from the needed constraints of multi-person teams.

Then we can begin to understand which of the common practices of BDD are only there to work around problems and can be discarded as needed, and which are truly foundational.

Try it out

Try using BDD on a personal project. Play the product owner, and write some Gherkin-style features. Pretend you can’t code. Really think about your problem without thinking about exactly how you’re going to solve it.

Whilst doing this, reflect on what practices you really need, and which you don’t. Which tools are less useful on your own? Which are more useful?

If you feel we’re just wasting time, I’d challenge us to think about what that’s telling us about our own ‘standard’ agile practice. How much of it is truly making us more agile, and how much of it is simply getting in the way?

How to layer context into your features using Real Narrative

April 2014

Take a look at this Cucumber feature and see what you think:

Feature: Power allocation on ship

  Blaster fire rippled across the rear of Charles's fighter. One of his engines immediately caught fire as the bullets tore through the outer casing, and the core reactor started to overheat.

  "Damn," thought Charles. He flung his ship hard left with one hand on the flight stick, using the other to knock out power to the damaged engine and route it to front shields. The large pirate cruiser loomed into view over his left shoulder. Slamming full power to engines and shields, he drove his ship straight towards the danger. Enemy bolts flashed off his shields like a mini light storm, but they held firm.

  Soon he was within range. With power to short range missiles and rear shields, he fired all three remaining missiles at the last possible moment, right at the belly of the enemy ship. Charles overshot the cruiser, pulling his ship around in a wide arc, keeping an eye out for their next move.

  Scenario: ...
    Given ...
    When ...

Preambles don’t have to be boring

This preamble uses real fictional narrative to make its point.

The whole point of the preamble is to provide this context for your feature. This allows the business and the customer to get the development of the feature right. Why shouldn’t we include some actual fiction to give us a flavour of the feature that’s required?

This might seem easier with a space shooter game, but narrative on any project, even one that is more business focused, will help to get across a sense of how the feature should feel.

If we employ our reader’s imaginations, it’ll help them connect to the intangible reasons for the feature that we can’t quite fit in a concise agile story description.

Proper context drives implementation

The narrative above gives me plenty of context to write stories such as these:

Scenario: Allocating full power to a single component
  When Charles allocates power to engines
  Then engines should be given full power
  And other systems should be dropped to minimal power

Scenario: Knocking out power to a component
  When Charlies knocks out power to a component
  Then the component should no longer receive any power
  And the component cannot be used
  And the reactor stops overheating

It also raises plenty of questions. What happens if I push full power to two seperate systems? How should that feel to the player? Should that cause overheating? Should it even be possible? The narrative has driven a conversation with more depth and richness that I might not have had otherwise.

Behaviour-driven development is for everyone

Who says that BDD is just for business web apps? It can work for games, too, any any other kind of software project. We’ve shown that in any domain where technical and non-technical people have to communicate about a software project, the core tenets of BDD are useful.

Whether it’s software for a space shooter or a sugar factory, real people are always involved. There’s always a translation process from great concepts to carefully crafted code. We should make that process as painless as possible.

Let’s choose to be interesting

The things we often write down in our stories are often the least interesting part of the conversation. Sometimes, in a drive to be pithy, we miss the point. How about we take a chance and include some actual narrative in our feature preambles and our story writing?

How are you leveraging the power of preambles to add context to your features?

Make Cucumber features more readable with this one weird trick

February 2014

“Sorry I’ve written such a long letter; I didn’t have time to write a short one.”

– Blaise Pascal

If you’ve got an issue with your customers not reading your feature files, then try this: it’ll help ensure their eyes stop glazing over.

As I travel around coaching teams doing BDD, a common problem I see with Gherkin features is that they are nigh on unreadable except by the people that wrote them… and even then, the writers often have trouble explaining what they mean.

This often happens when non-technical stakeholders have little to no involvement in writing features, leaving technical people free to be as obscure as they like. It’s easy to write an obscure feature: it takes a lot less effort to ramble and choose the first words that come to mind, rather than crafting carefully considered prose. The pain comes later: an obscure feature is imprecise, error-prone and unmaintainable, as the effort required to understand it will stop others from maintaining it.

How I help people simplify their features

When asked to review the language of a preamble, I read the feature out loud, and then ask the writer of the feature what it means.

A deep breath often follows. “Ok, this is the one where…” The writer will explain the feature clearly and concisely using completely different words to what is actually written in the feature. They use great contextual information that’s missing from the written preamble, and work to ensure I really understand what’s going on.

Once I’ve got a good response that I can understand, I ask the writer to replace the preamble with exactly what they just said.

It’s never exactly what they said (natural language is different to spoken language, after all) but it’s always better than what they had before.

Sometimes, when asked what the feature means, the writer will give a short hesitant explanation, and then proceed to read out the preamble again. My response is normally: “yes, but what does it mean?” Occasionally I have to ask five or six times until I get a considered, clear response.

This also works for scenarios, scenario descriptions, tag names, etc.

Why this works

Sometimes it’s easy for us to get so wrapped up in the detail of the features that we’re writing that we’re unable to see the wood for the trees. Our features read much more like computer code than they do plain natural language.

Features are communication tools first and foremost, and leveraging different ways of communicating while writing them will help to ensure they’re as carefully considered as possible.

(This works for natural prose, too. if you write a blog, documentation or even just emails to colleagues, taking a moment to read your text out loud will tell you in an instant whether it makes sense.)

A challenge

Pick a feature on your project, and read it out loud. If it makes no sense, explain what the feature does to a colleague and ask them to write it down for you. If it reads awkwardly and could be improved, take ten minutes to do so. Your future readers will thank you for it.

BDD Kickstart is dead. Long live...

November 2013

We are coming up to the one year anniversary of the first public BDD Kickstart, and we’ve got some news…

Matt and I have enjoyed running BDD Kickstart over the last year or so. We’ve had hundreds of people go through the course in all, with courses run for the public and privately in-house.

Over the year we’ve grown a team of real expert practitioners who also happen to be fantastic at teaching and mentoring. Seb, Rob, Julien and Steve have been partnering with us to help us run many more courses than we could have done on our own. With Suzan publicising and marketing the courses, we have built up some great momentum: enough to expand our course lineup.

BDD Kickstart’s fundamental philosophy has always been to put you in a room with experts. With the addition of new partners, we’re growing the range of subjects we can offer at that very high quality level. We can offer courses in more than just BDD. So we needed a new name.

Introducing…

Quality matters to us enormously, so we’re growing slowly. We’re focusing on running our existing Continuous Delivery course, and we’re already running in-house Ruby courses. We’re writing a “Hexagonal” course to teach pure OO design principles for modern web applications.

We’d like your feedback please!

We’re actively seeking feedback to help guide us as we grow and expand. Your emails are always welcome, but we’d especially like to speak to you on the phone if:

You have been on a course with us and you have some feedback or a testimonial
You’ve been thinking about coming along but haven’t done so yet for specific reasons (location, can’t spare the time, financial, etc)
You have an idea of a subject you’d like to learn from us that we don’t offer yet

Send us an email with your phone number or Skype handle and we’ll set up a call.

What’s next

We have two public courses available at the moment: we’re teaching our popular BDD Kickstart course in London in December and our Continuous Delivery course in Paris in March. If you’re interested in either of these courses, you can sign up for London now, or email us to express your interest in the Paris course.

It’s an exciting time for Kickstart Academy: we look forward to seeing you at one of our workshops soon!