Example Mapping: Red Cards Are Not Blockers

Four blue cards on the table. A dozen green ones spread underneath. The session is going well. Then someone asks what happens when a bulk job gets canceled mid-assignment. Do you roll back everything, or just the one job?

Silence for a second. Then someone says: "I think the answer is..."

And here's the moment that decides whether this Example Mapping session was worth the room's time: what happens next.

Many teams reach for the answer. Somebody in the room usually has one. It sounds reasonable. The group nods, writes it down as a rule, and moves on. Everybody feels good about it: the question got answered, the map keeps growing, the story stays on track for the sprint.

That relief is the problem.

The answer was already in the room

Here's the assumption a lot of people carry into Example Mapping: a red card is for questions nobody can answer. If someone in the room has a plausible answer, you don't need the card. You write it down and continue.

That assumption is wrong, and it's wrong in a way that costs you three sprints later, not now.

A red card isn't a marker for "nobody knows." It's a marker for "the wrong person is answering." Those are different failure modes, and only one of them is obvious in the moment.

Take the bulk-assignment question. Someone in the room offers an answer, maybe even a good one. But are they the person who owns that business rule? Usually not. Usually it's a developer making a reasonable guess about what ops probably wants, or a product owner guessing at a technical constraint that isn't theirs to guess at. The answer sounds complete, but it isn't. It's a decision wearing the costume of a decision, made by someone without the authority to make it.

Four cards, one discipline

Example Mapping itself is simple enough to explain in two sentences, which is exactly why teams underestimate it. You write the story on a yellow card. You write the rules you already know on blue cards beneath it. For each rule, you write concrete examples on green cards. And when the conversation surfaces a question nobody is positioned to close, you write it on a red card, and you move on instead of grinding the discussion to a halt.

That's the entire mechanic. Four colors, one table, roughly twenty-five minutes. What makes Example Mapping a BDD technique rather than just a whiteboard exercise is what those green cards become next: concrete examples that turn directly into Gherkin scenarios, the acceptance criteria your team will actually build and test against.

Four cards, four jobs. The red card isn't the odd one out. It's the one doing the most work.

Why the answer feels like enough

There's a name for what happens in the room the moment somebody offers an answer: the need for closure. It's a well-documented pull in group decision-making: people find open questions uncomfortable, and the discomfort doesn't scale with how important the question is. A trivial ambiguity and a business-critical one create the same itch to decide and move on.

Agile teams are especially exposed to this, because agile process is built around deferring decisions until you have more information, and deferring a decision feels exactly like the discomfort the group is trying to get rid of. The whole point of Big Design Up Front was that it promised closure early. It felt better, right up until the closure turned out to be an illusion and the real decisions had to get made anyway, later, under worse conditions.

Example Mapping sits in the same trap. The moment somebody offers a plausible answer, the itch goes away, and the itch doesn't discriminate between a trivial question and a critical one. That's what makes it dangerous: the group grabs the first coherent answer available and treats the discomfort as resolved, whether or not anyone checked if the answer belonged to them.

That's precisely why the red card has to be a deliberate, slightly unnatural act. It's you telling the room: the itch went away, but the actual problem didn't.

Knowing versus owning

So here's the practical test, and it's not "does anyone know the answer." It's "does the person answering own this decision."

Somebody who knows the domain isn't automatically somebody who's allowed to decide the domain. A developer can have a perfectly informed opinion about what should happen to a canceled job in a bulk assignment, and still not be the person whose job it is to make that call. The test isn't competence. It's authority.

This is a sharper standard than many facilitation guides apply. Even the more careful writeups of Example Mapping (the ones that tell you to assign an owner and a date to each red card) stop at process. They tell you what to do with an unanswered question. They don't tell you how to recognize an answer that only looks unanswered because the wrong person supplied it.

Two answers can sound identical in the room. Only one of them survives contact with production.

What the red card actually buys you

A red card doesn't mean the team is behind on understanding the story. It means the team caught itself before writing down a guess as if it were a decision.

That reframes what the card is protecting you from. Ignorance is easy to spot: nobody is fooled by an honest "I don't know." Confidence is the harder case, the plausible-sounding answer that gets treated as settled because settling it felt better than sitting with the open question one more minute.

A team that mixes those two up thinks it's being careful. It's just being fast, and the bill for that speed comes due in the sprint where the customer says that's not what they meant, and nobody can point to who decided otherwise.

Further Reading

Shift-Left with BDD: The Full Journey

Want to see the Red Card discipline played out in a full Example Mapping session? This course follows one feature from first conversation to production.

View the course