BDD Overview

The three practices we introduced in Chapter 1 - Discovery, Formulation and Automation - are meant to be done in a sequence, in a series of rapid iterations.

Many teams are not used to working this way, because they think that testing (where a lot of the discovery happens) is something you do at the end.

This is what the famous management consultant, W. Edwards Demming, ridiculed as:

Teams like this usually jump straight into Automation - writing the implementation of the feature. If they’re using Cucumber, they do a bit of Formulation - just enough to automate a test for the feature, but without really thinking very hard about what all the different scenarios are. They probably add these tests after they’ve done the implementation, or perhaps in parallel. They certainly don’t use them to drive the development of the implementation.

Finally, much of the Discovery happens at the end once someone has a chance to test the feature by hand, and really starts to think about the edge-cases.

Viewed from a BDD practitioner’s eyes, they’re doing everything backwards.

In software projects, it’s often the unknown unknowns that can make the biggest difference between success and failure. In BDD, we always try to assume we’re ignorant of some important information and try to deliberately discover those unknown unknowns as early as possible, so they don’t surprise us later on.

A team that invests just a little bit extra in Discovery, before they write any code, saves themselves a huge amount of wasted time further down the line.

In lesson 1, we showed you an example of the Three Amigos - Tester, Developer and Product owner - having a conversation about a new user story.

Nobody likes long meetings, so we’ve developed a simple framework for this conversation that keeps it quick and effective. We call this Example Mapping.

An Example Mapping session takes a single User Story as input, and aims to produce four outputs:

We capture these, as we talk, using index cards, or another virtual equivalent.

Working with these simple artefacts rather than trying to go straight to formulating Gherkin, allows us to keep the conversation at the right level - seeing the whole picture of the user story without getting lost in details.

We first developed example mapping in face-to-face meeting using a simple a multi-colour pack of index cards and some pens. For teams that are working remotely, there are many virtual equivalents of that nowadays.

We use the four different coloured cards to represent the four main kinds of information that arise in the conversation.

We can start with the easy stuff: Take a yellow card and write down the name of the story.

Now, do we already know any rules or acceptance criteria about this story?

Write each rule down on a blue card:

They look pretty straightforward, but let’s explore them a bit by coming up with some examples.

Darren the developer comes up with a simple scenario to check he understands the basics of the “buy” rule: "I start with 10 credits, I shout buy my muffins and then I want to buy some socks, then I have zero credits. Correct?"

"Yes", says Paula.

Darren writes this example up on a green card, and places it underneath the rule that it illustrates.

Tammy the tester chimes in: "How about the one where you shout a word that contains buy, like buyer for example? If you were to shout I need a buyer for my house. Would that lose credits too?"

Paula thinks about it for a minute, and decides that no, only the whole word buy counts. They’ve discovered a new rule! They write that up on the rule card, and place the example card underneath it.

Darren asks: "How do the users get these credits? Are we building that functionality as part of this story too?"

Paula tells him that’s part of another story, and they can assume the user can already purchase credits. They write that down as a rule too.

This isn’t a behaviour rule - it’s a rule about the scope of the story. It’s still useful to write it down since we’ve agreed on it. But it won’t need any examples. We could also have chosen to use a red card her to write down our assumption.

Still focussed on the “buy” rule, Tammy asks: "What if they run out of credit? Say you start with 10 credits and shout buy three times. What’s the outcome?"

Paula looks puzzled. "I don’t know". She says. I’ll need to give that some thought.

Darren takes a red card and writes this up as a question.

They apply the same technique to the other rule about long messages, and pretty soon the table is covered in cards, reflecting the rules, examples and questions that have come up in their conversation. Now they have a picture in front of them that reflects back what they know, and still don’t know, about this story.

As you’ve just seen, an example mapping session should go right across the breadth of the story, trying to get a complete picture of the behaviour. Inviting all three amigos - product owner, tester and developer - is important because each perspective adds something to the conversation.

Although the apparent purpose of an example mapping session is to take a user story, and try to produce rules and examples that illustrate the behaviour, the underlying goal is to achieve a shared understanding and agreement about the precise scope of a user story. Some people tell us that example mapping has helped to build empathy within their team!

With this goal in mind, make sure the session isn’t just a rubber-stamping exercise, where one person does all the talking. Notice how in our example, everyone in the group was asking questions and writing new cards.

In the conversation, we often end up refining, or even slicing out new user stories to make the current one smaller. Deciding what a story is not - and maximising the amount of work not done - is one of the most useful things you can do in a three amigos session. Small stories are the secret of a successful agile team.

Each time you come up with an example, try to understand what the underlying rule or rules are. If you discover an example that doesn’t fit your rules, you’ll need to reconsider your rules. In this way, the scope of the story is refined by the group.

Although there’s no doubt of the power of examples for exploring and talking through requirements, it’s the rules that will go into the code. If you understand the rules, you’ll be able to build an elegant solution.

As Dr David West says in his excellent book "Object Thinking", If you problem the solution well enough, the solution will take care of itself.

Sometimes, you’ll come across questions that nobody can answer. Instead of getting stuck trying to come up with an answer, just write down the question.

Congratulations! You’ve just turned an unknown unknown into a known unknown. That’s progress.

Many people think they need to produce formal Gherkin scenarios from their three amigos conversations, but in our experience that’s only occasionally necessary. In fact, it can often slow the discussion down.

The point of an example mapping session is to do the discovery work. You can do formulation as a separate activity, next.

One last tip is to run your example mapping sessions in a timebox. When you’re practiced at it, you should be able to analyse a story within 25 minutes. If you can’t, it’s either too big, or you don’t understand it well enough yet. Either way, it’s not ready to play.

At the end of the 25 minutes, you can check whether everyone thinks the story is ready to start work on. If lots of questions remain, it would be risky to start work, but people might be comfortable taking on a story with only a few minor questions to clear up. Check this with a quick thumb-vote.