Introduction To Example Mapping | Tips And Guidance

In its essence, the example mapping technique is rather simple. The first step should be, as we mentioned above, gathering people from your team who bring different perspectives. 

This group should at least include someone in charge of the product who will describe the problem and set the rules, a technical person, or a developer, who will ask if there is a satisfactory level of available information to solve the problem, and a tester who will observe the item that is the object of discussion from the perspective of “ What happens when?” Other members of the team are also welcomed, especially someone who can offer the user’s perspective on the backlog item, although overcrowding the room can hinder the efficiency of the process.

The process of example mapping itself involves four differently-coloured sticky notes, each for one aspect of the implementation of this technique. The colours themselves are not that important, but you should clearly determine which will stand for what and stick to it. To make things simpler here’s the colour-coded card system proposed by the creator of the example mapping technique, Matt Wynne:

• Yellow sticky notes should be used to define the story itself and serve as the headline for the entire example map.
• Blue sticky notes will indicate specific business and other rules directly associated with the story.
• Green sticky notes serve for defining the examples of the rules in the row above represented by the blue sticky notes.
• Red sticky notes are used for making note of the questions that arise during the discussion. These questions can be related to the examples, rules, or the definition of the story itself.
• Once you have this colour-coded system set up, you start by picking a story (backlog item) and writing it on the yellow sticky note. This sticky note will be placed at the top of the example map, serving as a header.

The next step is writing the business rules or the acceptance criteria that are already known to us on the blue sticky notes. These cards should be placed in the first horizontal row beneath the story (yellow sticky note).

Underneath the blue sticky notes with the rules, you’ll place green cards with one or more relevant examples for each rule written on them. Of course, the examples should be placed under the rule they refer to. As for the format of the examples, there are basically no restrictions, and you use gherkin criteria, friends-style format, or leave them unstructured, as long as everyone understands them.

As the conversation moves on and you fill the table or board with sticky notes, certain issues or misunderstandings will arise, either relating to a specific example or, perhaps the entire rule. All unanswered questions and issues that can only be resolved by people not currently participating in the discussion should be written on red questions and attached to the example map, preferably next to the example or the rule they pertain to.

Through conversation, you’ll soon be done with this basic setup and have a visual representation of how the team currently views the story. The large presence of certain colours on the table or board indicates the level of story understanding at that point. Plenty of red cards will mean that there are a lot of unresolved issues and that a team still has a lot to learn to gain a full understanding of a story.

If the blue colour is dominating the table, meaning that there are multiple business rules, the story is likely very large and complex. In that case, it’s a good idea to slice the story into smaller fragments and add the new, smaller slice to the backlog. 

Similarly to this, a lot of green cards with examples point to the complexity of the row above, indicating that rules are perhaps overly complicated. Just like stories, rules can also be set apart and then taken into consideration in smaller chunks. On the other hand, some rules will be so simple and obvious that you may not need examples at all.