Example Mapping is a simple but powerful tool. It can frame the conversations that help your team to build a shared understanding about what you are trying to build. It was discovered and popularised by Matt Wynne

If you haven’t heard of Example Mapping before, Matt’s post Introducing Example Mapping is a great place to start. Alternatively, if you prefer video you can watch Aslak’s Example Mapping webinar.

Both of those resources, and many others online and at conferences, are a great way to understand how Example Mapping works and why it’s useful.

But how do you get started with your first Example Mapping session for you team? Having helped several teams introduce Example Mapping into their practices I wanted to share my tips for getting started:

1. Pick a story. It doesn’t really matter what it is, except if you have “technical stories” they might not work as well. But pick one. Don’t try to do too much.

2. Give yourselves a time limit, and at the end have the team thumb vote on whether you think the story is ready. Twenty-five minutes is a good amount of time. If you get “no” at the end try to schedule another session once the questions and concerns have been answered

3. Don’t invite everyone. It might give you too much conversation. The sweet spot for me is 3 to 5 people covering at least the development, test and product perspectives. You can always run a second session on another story so other people can give Example Mapping a try.

4. Have someone take on a facilitation role. Their job is to look out for conversations that are sweating the details too much. If no one in the room can answer a question— add a pink question card. If the conversation is drifting out of scope — take note of a new story on a yellow card. Eventually the team will do this naturally, but having someone specifically watching for it can really help at first.

5. Don’t use Gherkin for the examples. Try drawing simple pictures or a simple notation that works well for your stories. We want the session to focus on discovery, moving to a formal language too early can stifle the flow of ideas.

6. Have the person who came to the meeting with the least understanding of the story write up the “minutes” of the meeting as Gherkin scenarios and share back to check understanding. Even better do it as a pair.

7. Do a mini retro at the end and talk about what went well, what didn’t and adjust for next time.

8. Blog about your experience — we all want to improve the practice so hearing about what worked and what didn’t helps everyone!

Have fun, and please do let us know how it went!

This blog post was originally posted on my Medium blog.