The two major goals of Behavior-Driven Development are better collaboration and automation. Even when the Three Amigos actually get together, collaboration can be tough. Where do we start? What scenarios should we write? What examples should be included?
Well, the Cucumber folks have a practice called “Example Mapping” to make it easier. All you need is a pack of index cards and a big table!
- Write the story under discussion on a yellow card at the top of the table.
- Write a rule for each known acceptance criteria on a blue card under the story.
- Write each example for a rule on a green card.
- Write each open question on a red card on the side to discuss later.
Keep writing cards until the team is satisfied with the story. This process provides clear, fast feedback for stories. It should take about 25 minutes per story. A team can quickly see if a story is too big or needs further refinement. Engineers can easily turn example cards into Gherkin scenarios. Remember to assign questions to owners to get answers.
Rather than duplicate documentation here, please read Matt Wynne’s seminal post on the practice, Introducing Example Mapping.
Also, watch this webinar recording from Cucumber about Example Mapping:
Automation Panda 
This is great information, thanks!
Nick | nkeene.com
LikeLike
Thanks, this was a great inspiration for me.
As soon as I had finished watching the video, I scheduled an Example Mapping workshop for two days later….well, sctually less of a workshop and more of a challenge:
I organized the interested colleagues in groups of 6 people, and promised to bake a chocolate cake for the team that came up with the best arrangement of cards – the one that promised to tell the most solid story for the user.
During the session, I placed the attendees in front of the wall with the cards, so whenever they came up with something, they could grab a card, write on it and place it on the wall. All I did was moderation like “Uh, that’s a valid question but we won’t find an answer in here, so make it a ‘question’ card” or “Well, that’s obviously important so we might right now decide to make it a ‘story’ card”.
I didn’t write a single card during the sessions.
Well….I was impressed of how much they enjoyed debating about ticket reservation, and the different approaches of different teams.
The next thing I will do is telling them: “OK, I admit, this example story was easy. Next (cake-awarded) challenge will be to come up with the best in-company example of a story for Example Mapping”.
Ideally this would be a quick way to actually use Example Mapping 😉
LikeLike
That’s awesome!
LikeLike
Are you interested in an Example Mapping tool? https://www.teamuplabs.com – it has drag and drop, story splitting etc.
LikeLike
Nice! Thanks.
LikeLike
Thank you very much for this insightful article.
We’ve developed Draft.io as a visual and highly flexible support, inherently collaborative. Let’s have a look at the following example if you consider performing Example Mapping in digital: https://draft.io/example/example-mapping
Hope it will be useful for some of you!
LikeLike
I am little bit confuse. Product owner will write the feature on Yellow card. The who will identify the rule? Team i.e. Developer & QA or product owner? Who will write the example relevant to the rule? Developer & QA or product owner?
LikeLike
The purpose of Example Mapping is to bring the three roles together (biz, dev, and test) to complete the activity together. Cards are not delegated to roles based on color.
LikeLike