What needs to be finished first
A User Story or backlog item is available as a starting point, at least as an "As ... I want ... so that ..." sentence with owner.
Product, Development, and QA are confirmed for the session, each with decision authority in their area.
What needs to be ready before start
Whiteboard or Miro board with four colors of stickies (yellow story, blue rule, green example, red open question); timer; link to backlog item; known edge cases from support or logs.
One facilitator (usually Product Owner or BA), one person from development, one person from QA or testing. Optionally a domain expert for corner cases. Maximum six people, otherwise discussion becomes slow.
Story title and draft acceptance criteria; current implementation of the closest flow; known edge cases from production; linked designs; estimated delivery slice.
25-45 min per story
Place the story card in yellow in the center. Beneath it, horizontal bands for rules (blue). To the right, examples (green) per rule. Red stickies are collected and not answered immediately. Set timer to 30 min, then decide on extension or postponement.
The one question this method answers
Which concrete examples show this story is complete, and what rule connects them?
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-5 min | 5 min | Read the story aloud and place it on the yellow card. Define context, goal, and out-of-scope briefly. No solution discussion, only understanding questions. | If implementation discussion starts this early, pause the timer and move back to value and user intent. |
25-20 min | 15 min | Collect examples: concrete inputs and expected outputs with date, amount, status. Each example as a green card with clearly observable result. | Examples like "normal case" are not usable. Ask for which user, which data, and what outcome. Explicitly request negative examples. |
320-30 min | 10 min | Derive rules from examples: blue card over related examples. One rule per cluster of examples with the same behavior. | If an example fits no rule, it is either an edge case (new rule) or out-of-scope (own story). Do not force it into an existing rule. |
430-40 min | 10 min | Review red cards for open questions. For each question decide: clarify before implementation (owner and deadline) or document as assumption with risk. | More than five red cards signal the story is not ready. Do not continue anyway, otherwise it returns through QA. |
540-45 min | 5 min | Review story splitting: if a rule belongs clearly after release, extract it as a separate story and prioritize it. | An example map with more than eight rules is often several stories. Splitting is not a failure of the method, it is its core value. |
What comes out at the end
Example map as photo or Miro snapshot plus structured capture in backlog item: story, list of rules with examples in Given-When-Then, open questions with owner and response deadline.
Store map snapshot with the session closing in the backlog item. Add late examples from test or production as an end edit with date and source. Create separate items for story split and link back to the origin.
Compact working template for Example Mapping with context, input, output artifacts, and next step.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
As a logged-in customer, I want to return a purchased item within 14 days, so I can reverse failed purchases.
Rule "Return cost at value threshold" is moved to own story PRD-58.
Recognize symptoms and steer against them
Green cards contain phrases like "normal case" or "error" without concrete data.
Require real values for each example: customer number, amount, status, date. If someone cannot formulate an example with data, they do not understand the rule.
The facilitator writes rules first, then examples are searched to fit.
Enforce sequence: collect examples first, then derive rules from them. This exposes gaps and edge cases that are invisible in abstraction.
Session drifts into detail research, one open question consumes 20 min.
Park red cards. After 30 min decide: clarify (owner, deadline) or assume with risk note. Clarification happens outside the session.
Map has 10+ rules, examples explode, discussion does not end.
Split rather than continue. One sub-story per rule cluster. Keep original story as epic and restart mapping per sub-story.
Negative examples and edge cases appear only in test, map remains optimistic.
Require at least one test-oriented person. Without QA the method becomes lightweight backlog refinement and misses core purpose.
Map ends on whiteboard, ticket still contains old acceptance text.
Directly copy Given-When-Then from examples into ticket afterwards. Ticket status can move to ready only after transfer.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.