All tools are summarized in Tools for a Consultant’s Work - Summary.
Example Mapping
The Example Mapping method was recommended to me by Kenny Baas, who uses it alongside Event Storming. This technique also works well on its own. It can be applied to gathering requirements, identifying edge cases, and determining questions we don’t have answers to.
This is particularly useful for groups strongly focused on task completion. Such individuals may overlook more difficult cases or not even consider them. Later, it turns out that a simple case has 20 different scenarios, and we end up patching things on the fly.
Example Mapping - https://xebia.com/blog/example-mapping-steering-the-conversation/
The technique is very simple. We start (usually) by listing all possible cases that we think need to be met. The longer we do this, the easier it becomes to identify increasingly difficult situations. Additionally, we list all the questions we don’t have answers to but should be answered.
These collected examples are then grouped into rules. This allows us, by way of completion, to describe additional cases that should be checked (e.g., to the rule of lowering the price through a discount, we can add an extreme case where the price is lower than the discount). Finally, we group these rules into stories, which are units of delivering a specific functionality. Usually, we don’t have to implement all cases from the start—we can divide them into those that will bring us the most value.
This technique allows us to separate the work on the solution from the work on the requirements and not mix these two things. At the same time, we can broadly consider particular cases. First, we define all possible ways of operation, and then we consider whether we actually need that kind of functionality. We can quickly remove unnecessary ones and create a system that includes only what we need.
Example of Use
A programming team complained about unclear requirements regarding the functionality being developed. The programming code subsequently had business gaps, which later caused problems in the system. At the same time, the business team dismissed the programmers' problems, saying they were delving too deeply into technical details.
Example Mapping allowed for communication at a level of shared values, starting from basic cases and gradually moving to more complex ones. A large part of the more difficult cases was immediately rejected by the business team. However, some were so critical that not handling them could undermine the entire system.
Why is it Beneficial?
A mental shift towards generating as many cases as possible helps define situations we wouldn’t normally find in the regular workflow. Based on this, we know what might await us and how to deal with it.
