Origins
Example Mapping was created by Matt Wynne in 20151, drawing on his work with Behavior-Driven Development and the broader specification-by-example tradition. Wynne's frustration was with backlog refinement sessions that ran an hour and produced stories the team still didn't really understand. He developed Example Mapping as a faster, more structured alternative that surfaced specifics and unknowns more reliably than open-ended discussion.
The format spread quickly through the BDD community and is now widely used outside it. Its appeal is its lightness: four card colors, a flat surface, and 20-25 minutes per story produces refinement most teams can't match with hour-long meetings.
The Four Card Colors
Each color represents a different kind of statement:
- Yellow — Story: the user story being refined. One yellow card per session.
- Blue — Rules: business rules or acceptance criteria. Generalizations about how the system should behave.
- Green — Examples: concrete examples that illustrate (or contradict) a blue rule. Specific scenarios with specific inputs and expected outputs.
- Red — Questions: open questions that need an answer before the story can be reliably implemented.
The layout: yellow story at top; blue rules in a column on the left; green examples to the right of each blue rule; red questions in their own area.
How the Session Runs
Setup (2 min)
Put the yellow story card up. Brief the participants: 25 minutes, the four card colors, the goal is to leave with clear acceptance criteria or with the questions we need answered before we can proceed.
Generate rules and examples (15–20 min)
The team works the story. As rules are proposed, write them on blue cards. As examples come up (often as counterexamples to a rule, or as edge cases that need handling), write them on green cards beneath the related rule. As questions arise that can't be answered in the room, write them on red.
The conversation alternates fast: someone proposes a rule, someone offers an example, the example reveals a missing rule or a question, the question gets parked, a new rule emerges. The cards capture each piece as it surfaces.
Read the map (3 min)
The team reads back the rules, examples, and questions out loud. The visual layout makes gaps obvious — a rule with no examples is probably abstract; an example with no rule probably means there's a hidden rule the team hasn't named.
Decide what to do with the story (5 min)
Three possible outcomes:
- Ready: rules clear, examples sufficient, red questions answerable or trivial. Story moves to ready-to-implement.
- Refine further: too many red cards. The team commits to getting specific questions answered before re-mapping.
- Split: the story is too big, the map is too sprawling. Break into smaller stories and map each.
What Example Mapping Reveals
The format surfaces information that unstructured refinement misses:
- Hidden assumptions: a rule that seems obvious turns out to have multiple interpretations. The first example that doesn't fit reveals the ambiguity.
- Missing rules: an example surfaces that no one can connect to a rule. There's a rule the team hadn't named.
- Hidden complexity: a story that looked like 3 acceptance criteria turns out to need 12. The map shows the actual complexity before the team commits.
- Out-of-scope edge cases: a green example surfaces that's genuinely interesting but not actually in this story's scope. Park it explicitly.
- True size: a story with 4 rules and 8 examples is meaningfully different from one with 12 rules and 30 examples. Mapping makes the difference visible.
Why It Works
Example Mapping is fast because it's structured. The four card colors give the conversation specific channels rather than letting it wander. Rules and examples push each other to be specific. Red cards capture questions without derailing the session into open-ended discussion. The time-box forces decision rather than indefinite refinement.
It's also genuinely participatory. Anyone can write any color of card. The PM doesn't have to lead; the developers don't have to wait for direction. The map emerges from the whole team's contribution.
Common Pitfalls
- Vague rules: blue cards that say "validate the input" rather than "the email field must contain an @ symbol." Push for specifics.
- Abstract examples: green cards that describe scenarios without specific inputs or expected outputs. "A user submits the form" is vague; "a user with no name submitted gets an error" is concrete.
- Skipping the red cards: the team avoids questions because they want the story to look done. Red cards are not failure — they're the most useful output of the session.
- Marathon mapping: trying to make every red card go away in a single session. If the questions can't be answered in the room, park them and move on.
- Wrong participants: only PM and one developer, no QA or designer. The format works best with diverse perspectives.
- Mapping after coding: using Example Mapping to document what's already been built. The format's value is in the refinement before work begins, not after.
Coaching Tips
Time-Box at 25 Minutes
The format depends on the constraint. Letting a session run an hour invites the open-ended wandering Example Mapping was designed to replace.
Push for Concrete Examples
"User logs in" is abstract. "User with valid password logs in successfully" is concrete. Specifics are where the value lives.
Welcome Red Cards
Questions are the most useful output of imperfect sessions. Teams that try to make red cards disappear at all costs miss the format's point.
Get the Right Voices in the Room
PM alone produces incomplete maps. Developers, testers, and designers each see different rules and examples. Cross-functional input is what makes the format work.
Split When the Map Sprawls
A story with 12 rules is two stories. Splitting at the mapping stage is cheaper than splitting mid-implementation.
Map Before Coding, Not After
The format's value is refinement before implementation. Using it to document already-built work misses where the leverage lives.
Summary
Example Mapping is one of the highest-leverage 25-minute investments a refinement practice can make. The structure compresses what unstructured refinement spreads across hours, and the four card colors guide the conversation toward the kinds of specificity that make stories implementable.
The format rewards practice. The first few sessions feel rough; the team's facility grows quickly. After half a dozen sessions, most teams find that they can refine a story to genuine readiness faster than they could before they started using the format. The investment in learning it pays off across every refinement session afterward.
- Wynne, M. (2015). Introducing Example Mapping. Cucumber Blog.