Color-Coding Rules, Examples, and Questions Exposes Hidden Scope Before User Stories Enter a Sprint

Like standard backlog refinement, Example Mapping breaks down software requirements into manageable pieces, but unlike standard refinement, it visually isolates the unknowns before estimation begins. The technique replaces open-ended discussions with a strict four-color card system. Teams map out a user story using yellow, blue, green, and red cards to expose hidden scope.[1]

Software development teams frequently struggle with ambiguous requirements that only reveal their complexity once coding starts. A user story might look simple on a digital board, but edge cases and unstated assumptions often derail the sprint. Example Mapping forces these issues to the surface immediately, preventing bloated features from entering the active development cycle.

Created by Matt Wynne in December 2015, the method limits the refinement conversation to a strict 25-minute timebox. The time constraint prevents endless debate and forces participants to focus on concrete examples rather than abstract architecture. If a story cannot be mapped within 25 minutes, it is automatically deemed too large or too vague.

The session relies on a collaborative dynamic known in Agile circles as the "Three Amigos." This involves at least three distinct perspectives: a product owner who understands the business intent, a developer who understands the technical constraints, and a tester who anticipates what could go wrong. Gathering these three viewpoints ensures a holistic review.

Structuring the Conversation

The process begins with a single yellow card placed at the top of the table, representing the user story itself. This card acts as the headline for the entire mapping session. If the Three Amigos cannot agree on what to write on the yellow card, the feature lacks the clarity needed to proceed.

Beneath the yellow story card, the team places blue cards horizontally to represent the business rules or acceptance criteria. These rules define the strict constraints of the feature. As Scrum Manager notes, "Some are written down... others live in the head of whoever knows the domain and go unsaid because they seem obvious, and those are the ones that sink deliveries."

To uncover these hidden rules, facilitators ask a specific diagnostic question. "A single question finds them best, and it is worth memorizing: is there any context in which this would be different?" This prompts the team to consider scenarios where the standard behavior changes, generating additional blue cards to capture the nuance.

If the table fills with too many blue cards, the visual spread immediately signals a problem. "If the blue colour is dominating the table, meaning that there are multiple business rules, the story is likely very large and complex," AM Digital explains. The team must then slice the story into smaller, independent deliverables.

Grounding Rules in Reality

Rules alone are often too abstract to guarantee shared understanding, which is why the technique requires green cards. Placed vertically beneath each blue rule, green cards capture concrete examples of that rule in action. These examples use specific data to illustrate exactly how the software should behave under those constraints.[1]

Examples serve a critical function: they make disagreement visible. Two team members might nod along to an abstract rule, but disagree entirely when presented with a specific data scenario. By forcing the team to articulate the exact inputs and expected outputs, the green cards eliminate subjective interpretations of the business rules.

Teams typically map three distinct types of examples to ensure comprehensive coverage. They start with the normal case, which illustrates the standard happy path. Next, they define the edge case, testing the boundaries, maximums, or empty values. Finally, they map the negative case, explicitly stating what the system must not do.

When a single blue rule accumulates a long vertical column of green example cards, it indicates excessive complexity. A dense cluster of examples suggests the rule itself is doing too much heavy lifting. The team must break that specific rule down further to ensure the development work remains predictable and testable.

Managing the Unknowns

The most powerful mechanism in Example Mapping is the red card, which captures questions that nobody in the room can answer. Instead of stalling the 25-minute session to debate an unknown variable, the team writes the question on a red card and moves on. This keeps the momentum going while documenting the knowledge gap.[1]

A map covered in red cards provides an undeniable visual metric of unreadiness. It proves that the team lacks the necessary information to begin development. The red cards become immediate action items for the product owner or subject matter experts to research before the story can safely enter a sprint.

This visual heuristic transforms scope creep from a semantic argument into a geometric reality. A wide map indicates horizontal scope bloat, a deep map reveals edge-case density, and a red map highlights dependency blockers. Teams can reject or approve a story based purely on this visual distribution, without needing to read every card.[2]

By catching these issues early, Example Mapping prevents the costly context-switching that occurs when developers uncover missing requirements mid-sprint. It shifts the discovery phase left, ensuring that the team resolves ambiguities when it is cheapest to do so—during a 25-minute conversation rather than during a multi-day coding effort.

Bridging the Gap to Automation

Example Mapping serves as the crucial bridge between product requirements and Behavior-Driven Development (BDD). Once the team agrees on the green example cards, developers and testers can translate them directly into executable specifications. These specifications often use the Given-When-Then syntax to drive automated acceptance tests.[1]

By establishing the examples before a single line of code is written, the team eliminates the traditional gap between what the product owner wants and what the developer builds. The conversation itself becomes the primary artifact, ensuring that edge cases are handled intentionally rather than discovered accidentally during code review or quality assurance.

The technique also democratizes the requirement-gathering process. Because the mapping relies on simple colored cards rather than complex modeling software, anyone can participate regardless of technical background. The product owner, developer, and tester all share equal responsibility for defining the feature's boundaries, fostering a culture of shared ownership.

Ultimately, Example Mapping proves that the most effective way to manage software complexity is to make it visible. By color-coding the knowns and isolating the unknowns, agile teams can confidently commit to user stories, knowing exactly what they are building and, more importantly, what they are explicitly choosing not to build.[1][2]