The success of a certain product depends on, more than anything else, delivering value to customers. Of course, this can only be accomplished by giving customers what they really need and fulfilling their desires regarding the product and its features. However, during the development process, the focus of product teams can often move away from the actual needs (and product vision and product goals
) of the customers which usually results in failing to provide a product that meets users’ expectations and solves a problem they may have.
Commonly, this occurs because those involved in development don’t have a clear picture of customer needs as they don’t ask the right questions and spend too much time worrying about specific features instead of keeping their sights on the big picture. Also, this is the main reason why user stories may have a poor success rate and may need to be reworked from scratch, wasting everyone’s valuable time and resources.
To avoid this and establish what makes a good and successful product or a feature, it is necessary to define precise user acceptance criteria based on customer needs and a thorough exploration of the problem domain. Nevertheless, discussions on how the development is supposed to move forward and how the product or its feature should be refined to suit the needs of the user can often be long, tiresome, and energy-draining.
This mainly happens because these conversations lack a clear structure that can help participants focus on the critical issues and efficiently come to a solution. However, there are techniques that can help you steer these sessions in the right direction and make them more productive, with example mapping is probably the best known and most efficient method of them all.
Table of Contents
What is Example Mapping?
Example mapping, first developed by Matt Wynne, is a technique used for refining and establishing clearer and better-defined user acceptance criteria for a certain user story. The basic idea behind this method is that multiple examples of specific cases that show how the story works offer better insight and provide more useful information than a single all-encompassing concept abstraction.
Through example mapping, those directly involved in product development, such as product owners, developers, and testers, can quickly and efficiently break down the product backlog of a given product by structuring their conversations around it.
During these discussions, the team(s) participating should flesh out user acceptance criteria and draw out relevant scenarios and ask important questions associated with the product or its feature. By asking these questions and using the examples of the rules, the participants in the session can explore possible solutions and come up with the one that is optimal for both the user and the organisation developing the product.
Furthermore, this technique helps them develop a shared understanding of the path forward and the need to add, remove, or adjust certain features. Having people who cover the various aspects of product development in the same room provides an opportunity to view a user story and a potential issue from different angles.
Product owners can provide an explanation of business rules and exemplary story scenarios, and developers and other members of the technical team can ask all the right questions about those rules and examples, while testers offer observations about how the feature will actually work.
Once the product team has a clear and unambiguous understanding of what’s expected of a user story and what the requirement is, they can also get the other key stakeholders involved in developing the acceptance criteria. Ideally, an example mapping session should result in identifying:
- The user acceptance criteria that will determine the constraints on the scope of a user story.
- Questions about the user story, or scenarios where the team isn’t certain what the expected behaviour will look like.
- Necessary assumptions needed to move forward.
- New product backlog items discovered during the process.
- Product backlog items that are deferred or removed from the development.
How does Example Mapping Work?
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.
How Long Should Example Mapping Session Last?
One of the big advantages of implementing the example mapping technique is that it takes only a chunk of your time and allows the team to efficiently use their time and resources to define acceptance criteria and explore the user story. A well-prepared team should be able to create an example map for an average-sized story fairly quickly, The time box in which the example mapping will take place should take no more than 25-30 minutes.
Setting the timing in advance will help the flow of discussion and allow things to swiftly move forward. Example mapping the story in the set time commonly means that it’s ready to be put into development. Once the set time expires, the team can vote by putting their thumbs up or down base on whether they think that the story has been properly mapped and the acceptance criteria have been set in a satisfactory way.
If the time box is not met, it means that the participants probably should practice more, or that the user story example map has too many rules or too many questions, In that case, it should be reworked and refined from the beginning.