Example Mapping, the Most Underestimated Agile Practice

We’ve all been there as developers: the Product Manager (PM) hands you a User Story whose description fits on a single line, “because it’s obvious.” Oh, really? Well, if it’s obvious, let’s get to it. Of course, your brain starts working before you even write the first line of code, and suddenly, nothing is obvious anymore. There are endless edge cases, gaps in the logic, and, if you look closely, half the time, a User Story that makes no sense in the first place.

We think better as a group

Does this mean the PM is bad? No. Does this mean the PM did a poor job? Yes, because he (or she) worked alone. We think better as a team than alone. Thus, design is not solely the PM’s responsibility. He is responsible for it, certainly, but functional design is also the developers’ responsibility. It cannot be stressed enough: a good developer is, among other things, an expert in the business domain. And before that, to develop effectively, it’s important to understand what you’re trying to build and why you want to build it. Allowing developers to get involved in the functional design helps bring to light all the pushback you need much more quickly.

Based on this principle, Example Mapping, introduced in 2015 by Matt Wynne, suggests bringing together the various roles involved in developing a User Story: PM, Dev, and QA. Even though this practice doesn’t guarantee a perfect functional design (it might still require minor adjustments), Example Mapping still avoids a lot of back-and-forth during the development and acceptance testing phases, or, even more costly, once the software increment is in production. Let’s say your design will be 90% right rather than 20% right without Example Mapping.

Working with examples

To that end, Example Mapping encourages us to work with examples. We have an unfortunate tendency to think in abstract terms, which is risky because the abstractions we deal with are rarely well-defined. Saying that Jean-Luc Mélenchon and Olivier Faure are on the left is probably true, but in reality, they will rarely agree. There’s the left, and then there’s the left.

Examples therefore allow us to test business rules and grasp the full complexity of the subject. Here’s an example: what does it mean to add fractions? 1/3 + 1/3 = 2/3, it’s clear: I can cut a cake into 3 equal pieces and take 2 pieces. But 1/2 + 1/3 = 5/6, that’s already something else. And 1/2 + 1/2 = 1/1, that’s yet another thing.

Oh, and then there’s the 1/0 case, which shouldn’t even be possible to write. Choosing actual values—as opposed to variables such as “numerator” or “denominator”—immediately brings edge cases to light.

Finally, these examples serve as acceptance tests. For a developer wanting to test their code, the first challenge is knowing which values to choose, even for a manual test. Most likely, I won’t use the same values as the PM, so I’ll deliver code in good faith that they might find doesn’t work. These examples and tests can therefore be viewed as a contract binding the PM to the developer. A contract that is an integral part of the Definition of Done.

4 colors to structure the discussion

The Example Mapping framework is based on four colors:

• Yellow 🟡: the User Story that is the focus of the session;
• Blue 🔵: business rules;
• Green 🟢: examples (generally several per rule);
• Red 🔴: questions without an immediate answer.

You can explore the topic however you like, starting either with the rules or with the examples. In the end, you’ll need both anyway:

• A rule is worthless until it has been tested with examples: without examples, major misunderstandings are likely to remain, and you’ll need examples and tests to validate the work.
• A single example is worthless, because based on one example, one could infer several rules (what, for example, can be deduced from f(1, 1) = 1? Is the function f multiplication? division? something else?)

A tool that gives you quick feedback

Example Mapping provides us with immediate visual feedback, which is useful for running the workshop effectively:

• Too much Red 🔴: the topic isn’t ready; you risk developing features that miss the mark; hold off;
• Too much Green 🟢: we need to move toward abstraction; a series of examples does not replace a rule;
• Too much Blue 🔵: you’re stuck in pure theory; you think you understand each other, but nothing could be less certain. Use examples to test your business rules and likely uncover many edge cases.

And a lot of yellow? That means you’ve done a good job, putting off all topics except one, the next thing to build. And yes, Example Mapping is at once a tool for design, decomposition, and prioritization. These activities are inseparable.

Conclusion

Example Mapping is a concrete, actionable Agile practice. Rather than struggling to create sprints that, even when well-executed, remain of questionable value, invest in this concrete and easy-to-implement practice; it will undoubtedly help you.

When you really think about it, discovery and functional design mark the beginning of the software development process. Succeeding at this stage is no guarantee of success at the end of the process (it’s not a sufficient condition), but it is still necessary.

In other words: 💩 in ➡️ 💩 out.