liveBook · Manning

Example Mapping

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

Example Mapping is a collaborative technique for organizing rules, examples, and questions to clarify requirements and discover acceptance criteria.

Example Mapping organizes rules, concrete examples, and questions around a user story or use case. It clarifies acceptance criteria and constraints when a discussion needs more detail than a timeline model provides. EventStorming can supply useful input, but Example Mapping also works independently. section 2.3.3

Use a concrete collaborative sequence:

  • Write the stakeholder-provided user story or use case on a yellow sticky. section 2.3.3
  • List known rules beneath it on blue stickies. section 2.3.3
  • Discuss specific examples for each rule, using them to expose constraints, new rules, and unanswered questions. section 2.3.3
  • Keep the conversation visible with a virtual board or physical index cards, then turn discoveries into decided acceptance criteria. section 2.6

Reserving seats

A “Reserve Seats” command may lead to “Seats Reserved” or “No available seats found.” Example Mapping probes the rules behind those outcomes, such as allowing only one ticket per seat or requiring adjacent seats for a single reservation. section 2.3.3

Complex scenarios need careful facilitation. Prepare enough structure to keep examples visible, but avoid so much structure that it fixes the group’s thinking. Model the conversation yourself when participants stop visualizing, ask what evidence could change a conclusion, and provide an example before stepping back. section 7.3.1 section 7.5

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes
Explains a visual facilitation sequence from user story through rules and examples, without descending into implementation details.
Examples
Uses seat reservation outcomes, sticky notes, Miro boards, physical index cards, and group sessions shaped by cognitive bias.
What it assumes
Assumes a stakeholder-provided user story or use case, while explicitly requiring no prior EventStorming.
What you can do after
Apply it via Miro or physical index cards to expose scenarios, constraints, and acceptance criteria collaboratively.
How it connects
Connects acceptance criteria and constraints with user stories, use cases, EventStorming, and Behavior-Driven Development.

Also explained in

Compare how 3 books explain Example Mapping →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.