How does an Example Mapping session run, and what do its four card types capture?

### Why a discovery conversation needs a structure An unstructured discovery workshop drifts. The group circles the interesting rule, forgets the dull one, argues an unanswerable question for eleven minutes, and leaves with a feeling of agreement and no artefact. **Example Mapping** is a lightweight technique from the BDD community that fixes this by making the conversation visible on a board while it happens, with four card types and a hard timebox. ### The four card types - **Yellow -- the story.** One card at the top naming the requirement under discussion. There is exactly one; a second yellow card is the signal you are exploring two stories at once. - **Blue -- a rule.** One card per rule or acceptance criterion the story must satisfy. Rules are written in business language and are deliberately short. - **Green -- an example.** A concrete illustration of one rule: specific inputs and the specific outcome they produce. Green cards sit under the blue card they belong to. - **Red -- a question.** Anything the people in the room cannot settle: a missing decision, an unknown downstream constraint, a stakeholder who needs asking. Writing the red card is what lets the group move on instead of stalling, and the cards are chased after the session. ### The rhythm Someone reads the story. The group states a rule, then immediately tries to make it concrete: "give me an example." Examples very often *change* the rule -- an example that does not fit forces a rewrite of the blue card, or splits it into two. When a question arises that nobody present can answer, it becomes a red card in a few seconds and the group returns to the rule. The timebox is around twenty-five minutes for one story; over-running is itself information. ### A worked map For a **utility billing run**, the story is "bill a household account for one monthly cycle": YELLOW bill a household account for one monthly cycle BLUE usage above the tier-1 cap is billed at the tier-2 rate GREEN 501 units -> 500 at tier-1, 1 at tier-2 GREEN 500 units -> all at tier-1 (cap inclusive) BLUE a cycle with no meter reading is estimated from the last three cycles GREEN no reading, three prior cycles present -> estimated bill, flagged as estimated RED what happens when fewer than three prior cycles exist? BLUE a closed account is billed only to its closure date The third blue card has no green card under it. That is a visible gap: the rule was asserted and never examined, and it is exactly where a defect will later be found. ### Reading the map as a signal The shape of the finished map is the real output, alongside the examples: - **Many blue cards** (say seven or eight) -- the story bundles several stories. Split it along rule lines. - **Many red cards** -- the story is not understood well enough to build. This is a far better finding at the board than three days into the work. - **A rule with no green card** -- unexamined. Either nobody could think of a case, in which case the rule may not be real, or the group ran out of time. - **A green card that fits no blue card** -- there is a missing rule. Adding it is often the most valuable minute of the session. - **A clean map** -- two or three rules, a few examples each, no open questions -- is the readiness signal. Note that this is a *content* signal about one story, distinct from the entry criteria a test process defines for a whole test effort. ### Where the cards go afterwards Blue cards become the acceptance criteria on the story. Green cards become the examples in those criteria and, for the rules worth automating, the scenarios of an executable specification -- which is why it matters that the green cards use the business's own words for the business's own concepts. When the words survive from the green card into the scenario, a stakeholder can still read what was automated; when someone rewrites them in implementation vocabulary at the hand-off, the audience for the specification quietly disappears. Red cards get owners and answers before the story is built. A team that leaves red cards to rot is running the ritual without the mechanism: the question was raised and then swallowed, and it will be answered by whoever writes the code, alone, with a guess. ### Common misuses Filling in the cards after the design is decided turns the map into documentation of a conclusion. Writing examples that restate the rule in other words ("a large usage is billed at the higher rate") adds a card without adding information -- an example must have specific values. And treating the map as a permanent artefact to store and maintain misses the point: the cards are scaffolding for a conversation, and once their content has moved into criteria and scenarios, the cards themselves can go in the bin.