While Bruno Boucard, Thomas Pierrain, and I were preparing our DDDEurope 2019 workshop, we discussed how to approach Example Mapping. For the workshop, we were combining EventStorming and Example Mapping to go from problem space to solution space. The way I have been approaching Example Mapping was slightly different then Thomas and Bruno did. Mine followed up more on EventStorming, standing in front of a wall storming examples first with stickies. Bruno and Thomas do it the way that was described byMatt Wynne from cucumber, standing in a group around a table, starting with a user story and one rule written on index cards. So we began to discuss in short what these difference are, and what the trade-off was when we did these. In this post, I will explain the different heuristics on approaching Example Mapping in this post.

Approaching Example Mapping

For who don’t know Example Mapping yet I would advise you to read up on it on the cucumber blog post. It is a great tool to use for collaborative deliberate discovery and modelling. The tool itself can be learned and understood effective within less than an hour. It makes refinement much more effective and fun to attend. I have facilitated and taught Example Mapping a lot of times, although I started as the blog post described, around a table with index cards, I have been experimenting with different approaches to it in the last year.

Table or wall approach

The way Matt described in his post how to approach Example Mapping is standing around a table using index cards. While the blog post doesn’t explicitly tell us to do Example Mapping around a table, Bruno explained to me the reason for it. If we are standing around a table side to side, it feels intimate, you can look at each other directly in the eye and are standing on the same level. Standing on the same level helps team building, it shows we are all equal which is extremely important when sharing knowledge.
Now the way I have been doing Example Mapping nowadays is usually right after an EventStorming session. On the left or right side of the EventStorm, I create some space to do an Example Mapping and will use stickies instead of index cards. While this will make Example Mapping slightly less intimate, it does give us an excellent overview of the whole story with the examples. We can even map our examples directly under the rules of an EventStorming session, but watch out not to couple both of them too soon. Both EventStorming and Example Mapping are tools used to discover the knowledge of your domain quickly and to create a shared language through conversations.

Guiding heuristics

I still use both of these approaches. When I need to boost team bonding or break hierarchies, I will use the table approach. For the rest, I always use the wall especially when combining with EventStorming I can roll up our outcomes and hang it close to where the team sits. Also for personal reasons, since I am tall a table usually is to low for me to work for a long time. Which can be positive because then we have a natural time box.

Rule or storming examples first approach

Bruno told me more of the original story of Example Mapping. When consulting for big financial corporates, there was not a lot of communication going on in refinements we get some business requirements but no context at all. This way it was hard to discover what we need to build. Example Mapping was invented to pull a user story from the backlog and let that person tell their story about it. With example mapping, we write down the first business rule to start finding concrete examples for that rule. While talking about the specific examples for that rule, more rules and examples will begin popping up in these conversations. In these conversations, we deliberate discover more examples and rules and can visually decide to split a user story or not.
Now when we use Example Mapping after an EventStorm a lot of rules already have been discovered. Because we already know a lot of rules I like to use a different approach, storming examples first. Since we already have the whole story visualised with EventStorming, we might still have blind spots. So I ask everyone to write for themselves concrete examples on stickies. The examples are about the story we just event stormed. I don’t impose any structure or boundaries here, anything goes. Be ready for total chaos! After the storming is done, we start having discussions about the examples, find examples that are double or are not crucial to implementing the story. See now if we can vertically order them by a rule. Ordering the examples by rule can be confusing at times; we don’t need to be perfect. As soon as we think we have ordered enough, we can discuss each vertical story from left to right and specify the rules for them. Eventually, we can slice the map up and perhaps split them into separate user stories on our backlog.

Guiding heuristics

Again here I still use both approaches. When I don’t have a complete story or the story is vague I would always start with the rule approach and let the story unfold from there. If the story is more concrete and visualised by for instance EventStorming we tend to get more of a streetlight effect, so stepping away from it and go with the storming examples approach helps in my experience to find more blind spots.
As you see there are many ways of approaching example mapping or any other facilitation technique/tool. The best is as soon as you feel comfortable to experiment with them as you can, find out new heuristics and share them. This way building up your own person heuristics for collaborative modelling.
Also, this post is published on my personal blog site.