In my previous article I have given a brief introduction to Example Mapping (a requirement workshop facilitation technique often used with Behaviour Driven Development) and listed a few tips how to avoid requirement gaps. Based on the feedback of that post, I thought I would write a few more posts about Example Mapping, to answer the common questions I usually receive whenever I show this technique to someone.

This time my focus is on the facilitator role. Example mapping is a structured conversation technique. This means that the discussion follows a specific structure in order to avoid endless discussions. In my experience, even mature teams might diverge from the agreed structure unless there is someone who guides them. This is why example mapping defines the facilitator role.

When people hear about facilitators, they usually associate them with the Scrum Master role and expect that they might need deep knowledge or formal training in example mapping to be able to fulfill this duty. Fortunately this is much more simple than that. I will share a few tips I use when I do example mapping facilitation.

Who can be the facilitator?

Practically anyone. Facilitating an example mapping session is not that difficult and it does not require deep domain or technical knowledge, so probably anyone in the team (including junior members) can try doing it. When I do example mapping with a team I even encourage them to choose someone else for each example mapping session. Once you have been a facilitator, you will feel more responsible for the product that the team is going to deliver.

I have just said everyone can be the facilitator, but there is one exception. As the most of the dialogues during example mapping will take place between the business representative (e.g. Product Owner, PO) and the team, it is not practical to choose the PO as the facilitator (because then they would need to discuss things with themselves). But our aim is to achieve team collaboration.

The facilitator needs to start or stop discussions and also needs to write notes onto index cards, so people think that only a verbally dominant person with good handwriting can be a good facilitator, but this is not necessarily true. It is ok if you are a good enough facilitator. Sometimes a more silent person can help to keep the discussion calm. Sometimes people will better concentrate on the index cards of someone, whose handwriting is not that readable. Try it!

However, one thing is very important: the team should respect and help the facilitator. So for example if there is a dominant person in the team who “pushes down” a more reserved facilitator, the other team members can also help holding back the dominant person. Don’t forget: next time even you might be the facilitator, so establishing a supportive culture means that you will also be helped and respected.

You, the facilitator

OK. So let’s imagine that now you are the facilitator of an example mapping session. Don’t worry, it is going to be fine!

Here are my tips you can consider. Feel free to change and extend them — it has to be you at the end. (Please share any other good tips you have discovered as a comment to this post.)

1. Have a good start

During the example mapping session, we are going to discuss the details of the rules (acceptance criteria) that define the scope of the user story. There are simpler and trickier rules. Probably the majority of the team is more excited to go for the tricky ones (not to “waste time on trivial stuff”). This excitement is totally understandable, but usually not that effective, because

• we would like to discover “unknown unknown” things and because they are unknown, we don’t know which rule and example will bring it up. Maybe the most boring one will trigger a good discussion that helps discovering it.
• We would like to enable collaboration. But collaboration is not only a game of the louder people. There are probably also juniors or members with less domain knowledge who would benefit from seeing the big picture first. (But maybe they are too much afraid to ask for it.)

As a facilitator, your need to guide the team to discuss the rules in a natural order (in the Discovery book, we call this “progressive focus”). In the majority of the cases this means that we should discuss the more general rules first and only go into the special cases later. (If the story is about a feature that guides the user through a longer business workflow, the order of the most common workflow steps might be also a good way to discuss the details. But don’t go to the exceptional cases too early.)

I usually choose a kind of “happy path” rule first. Like “the users should be able to pay by card”. As mentioned earlier, this is probably not very tricky (the interesting things will come when we discuss the specialties of a concrete card type, like AmEx), but finding a few examples for this “happy path” rule helps

• to get an overview of the process
• to learn about the different actors who will influence the flow (like what kind of users will use this, whether the “system” will also make decisions and performs actions, etc.)
• to learn about the most important events
• to learn about the most important outcomes that influence the overall success of the story.

These are very useful pieces of information for a novice team member, but actually it is also very useful for the remaining part of the meeting as we will have a common agreement on the domain language we use (how we call what).

I often have very useful discussions triggered by these “simple” examples, so I never miss them. If the people complaining (“Why do we waste our time with simple things?”), my usual suggestion is to test ourselves: If it is really simple, we will not spend much time with it anyway. And it is really like that, sometimes we can get it done in 5 minutes.

2. Keep asking for examples

People somehow expect that if everyone is aware of the technique we use (example mapping in our case), everyone will “just do it”. Maybe this happens sometimes, but in the majority of the cases this ends up  with people staring at each other and waiting if the others say anything. This is when the facilitator can help. It is very simple. Usually saying “Let’s find an example for this” or “Is there any other example that would be relevant?” is just enough to make the meeting flow.

3. Let examples drive the discussion

Make sure that you let the meeting be driven by examples. E.g. saying “Could you please give an example for this rule?” is much better than “Could please explain the details of this rule?”. The latter might trigger an unstructured discussion.

Focusing on the examples is a good and gentle way of cutting pointless debates. For example if there is a discussion between two participants and they cannot agree (maybe the discussion is even getting more heated), I usually suggest them to express their point in a form of an example (“Could you please make an example that illustrates your point?”). In many cases it turns out that  the problem was that they misunderstood each other; seeing the concrete examples, the rest of the team can also better form their opinion.

4. Trigger discussions (scratch the surface of domain knowledge)

As I mentioned earlier, our goal is to discover things that we might not know. The biggest enemy of this goal is silence, or statements like “all clear”, “OK” or “Yes, we know this”.

In these cases the facilitator should somehow trigger discussions to make sure that everyone is on the same page. In my previous blog post I shared 5 tips for this. Essentially what we are doing here it to scratch the surface of team’s domain knowledge a little bit.

5. Be selfish in a good way

Everyone can be an example mapping facilitator. Maybe you are not the one with the deepest domain knowledge or the one with the fastest hand writing, but don’t worry. The team will respect this.

For example, I cannot write and listen at the same time, so when I facilitate an example mapping session I have to ask the people to stop the discussion until I am finished with putting down the previous example. In the beginning I felt like I was the bottleneck, but later on I realized that having a few seconds of pause is not necessarily bad. Everyone can calm down a bit, collect their thoughts and last but not least, they can double check that the example card I have just written really explains what we have discussed.

I had similar experience when I had to stop the discussion and go back to the basics when I was new to the domain and could not follow the discussion. I am sure I was not the only one…

So feel free to stop the discussions or ask “stupid” question, if you need that. It is going to be for everyone’s good.

6. The goal is: understanding

Sometimes the discussion goes into a detail analysis of all possible cases. Since the examples are like test cases, people often feel that this is the meeting where we have to build the “full coverage” with them. But this is often not the case.

Our primary goal with discussing the requirements together is to get a shared understanding. Sometimes we need to discuss important edge cases as well, of course, but this does not mean that we have to cover all possible cases with examples.

The line between the examples needed for understanding and the examples (tests) needed for ensuring the expected test coverage is a bit blurry. But as a facilitator, make sure that everyone understands our goal for now: better understanding.

Once the discussion goes into a test-case discovery direction, suggest them to have that discussion as a separate meeting, where with a smaller group they can collect the cases that are necessary for testing. If we have the impression that we have a good and general understanding of the rule with that few example we collected, we can move on to the next one.

Another common way of missing the “understanding” goal is overspecification. We are interested to get information to understand what we need, so that we can deliver the given story, but only that story.

I explain this through an example. Imagine you need to discuss the details of a registration process where – among other things – we need to collect data from the users that conform to some form. So we need a couple of validations. The majority of them are simple mandatory fields, length and range validations, but there are a plenty of them. If you would like to “properly” cover a range validation with examples, you would need ~7 examples (below, at lower range below, at lover range above, in range, at higher range below, at higher range above, above). With an average size of registration form altogether this would mean more than 50 examples. Just for validation. Is that really helpful?

In usual projects you don’t need to develop validators yourself. There is typically an external component that does that, you only need to configure the existing validators for the individual fields (e.g. set the boundaries for a range validator). So if the team is generally aware how “mandatory”, “length” and “range validator” works, it is enough to have a single overview list that mentions all registration fields with their validation details, not a pack of examples for each one. (Maybe even that one can be better prepared by a pair of people, not the entire team.) Focus on whether we properly understand the registration process and the related business rules rather.

Now you are ready to go!

Now you see that really everyone can be an example mapping facilitator. And it is not a hard job once you get a bit of practice. I hope that with my tips I was able to help you a bit to become a good enough example mapping facilitator.