Shaping user stories with “example mapping”

TL;DR

We introduced example mapping workshops as soon as we set up the development process at the beginning of the Gravity journey. Example mapping is a workshop for Agile teams to help structure conversation when working on a new user story. It has multiple benefits:

Software development teams often struggle to align themselves on “what” exactly should be developed. Usually, things are done this way: product people come with requirements for the new feature they would like to see. Then, developers implement it, and testers ensure there is no defect and the business requirements are met. 

It looks like the Chinese Whispers game, isn’t it? Like in this game, what we have at the end of the chain is not exactly what we were expecting. That leads to bewildered product managers, a global climate of confusion and defiance, and wasted money and time.

Well, happily, there are ways to build a shared understanding of what needs to be done. This is -for the whole point of behavior-driven development.

In this blog post, I will present a workshop I particularly enjoy for its easiness and efficiency: example mapping. 

A lot of teams already discuss the requirements of a new feature before the development starts. For example, during planning poker, three amigos sessions, or dedicated discovery meetings, for instance. 

Unlike these free-form meetings, the point of example mapping is to structure this conversation concisely and powerfully, using concrete use cases of the new feature, known as “examples”. 

Using examples as the starting point of the conversation has multiple benefits:

First, gather the three amigos: product manager/owner, developer, and QA engineer. Diversity in points of view and skills will help you have the most fruitful conversation. Give everyone a pack of colored index cards (or sticky notes) and pens, set a timer to 20~30 minutes, and you are all set. 

For remote teams, collaborative whiteboard tools like Miro will do the trick.

After a while, your example map will look like this:

The “typology” of the map should give you a few hints about whether you are ready or not to work on the user story:

I discovered this workshop when working with the Cucumber team back in 2019. The whole development team quickly bought it as the benefits were immediate: more focused increments, better alignment of the team members, expected features were delivered more quickly, and so on. I also introduced it when I joined the Gravity team, and it helped us stay focused on our core value proposition. 

After a few years of practice, here are a few tips I figured out along the way that should help you facilitate this workshop with your team:

Example mapping triggers an intense conversation, and the participants will quickly be exhausted. Set a timebox for 30 minutes. After some practice, we are now able to make it in 20 minutes. If you feel like you are close to finishing, suggest taking a few extra 5 minutes to conclude.

When the conversation flows, it becomes easy to forget to capture examples, rules, and questions. When running this workshop, we always have one person ensuring everything is noted on the cards. The facilitator also timeboxes the conversation and handles all the logistics (book a room, invite people…). 

When should you plan this workshop? Too long before, and people will forget why behind some rules and examples. Just before development begins will make you have a tough time gathering enough people for a last-minute meeting (and you will have to postpone the development of the user story). Here at Gravity, we try to refine a user story around a week before development starts. In a former team, we used to have two time slots in the week dedicated to example mappings, so the discovery work was done ahead of time. 

Using concrete examples as the basis of the conversation is a powerful way to challenge the behavior of the new feature and imagine how it will look in the hands of our users. Unfortunately, it is not as natural as we imagine, and I often see participants talk generics first rather than specifics. The problem with generics is that everybody in the room can have their own understanding of it, which is not quite the purpose of the example mapping activity. Encourage people to tell stories, using real-life data to illustrate them (for example, use actual people’s names instead of “the user”) or even draw their examples (which can be far more efficient than natural language in some cases)

Don’t limit yourself to the four types of artifacts I discussed above (user stories/rules/examples/questions). For example, during these sessions, it is common to discuss technical or UX details related to the behavior of the US. In our case, it frequently happens when we discuss new features involving the data we collect for Gravity and how their format could be impacted. This is why we introduced “Tech rules” and “UX rules” in our example mappings workshops.

This article is just an introduction to example mapping. If you want to give it a try with your team, there are plenty of resources on the web. Here is a short list of those: