Agile Workshop method

Example Mapping

Clarifies a story for implementation through business rules, concrete examples, and open questions.

Example Mapping is a short BDD-oriented team conversation before implementation. The group starts from concrete examples, summarizes business rules and records questions, assumptions and newly discovered stories.

Core question

Which rules and cases must be clear so this story can be understood and tested?

Plan the session Method guide

Start comparison

Give feedbackIs this method useful to you?

Participants: 3-7
Time: About 25 minutes per story

One focused map per story; colors are common conventions and can be replaced digitally.

Paper illustration of a yellow story card, blue rule cards, green example cards and a red question card on a light workspace.

Focus
Focus one story
A clear user story frames the clarification.
Rules
Elicit business rules
Describe general conditions that constrain the intended behavior.
Examples
Explore rules with examples
Concrete cases show how a rule applies in typical and variant situations.
Questions
Capture questions and next steps
Unanswerable questions stay visible and become actionable follow-up.

Update the story and examples when domain decisions or new learning arrive. Keep open questions visible with an owner and due date.

A good fit when

Use it when a user story needs clarification and examples that can guide acceptance tests.

Ideal for

BDD discovery
Backlog refinement
Complex stories

Not good for

Strategic portfolio work
Very large roadmaps

Outputs

Clarified story
A bounded change as the shared focus.
Rules and examples
Testable behavior rules with concrete examples and counterexamples.
Open questions
Unresolved points with an owner, due date and follow-up decision.

Example Map

Fictional teaching example

One story with rules, concrete examples and unresolved questions. Card colors follow Cucumber’s documented convention.

Story · yellow

Which single change are we clarifying?

As a member, I want to reserve a tool so it is available for my repair.

Rules · blue

Which general business condition applies?

R1: A confirmed reservation states the tool and collection time. R2: If the tool is unavailable in the requested window, no reservation is confirmed. (Both rules fictional)

Examples · green

Which concrete precondition, action and outcome illustrate the rule?

F1: A person reserves on Monday for Wednesday. The confirmation names Wednesday as the collection day. (Fictional)

Questions · red

What remains unresolved, and who will clarify it by when?

Fictional open question: What happens if the previous loan is returned late? Add an owner and due date before implementation.

The examples are fictional. Yellow for story, blue for rule, green for example and red for open question follow Cucumber’s documented card convention; digital labels also work.

Source: Cucumber

First step

Choose one suitably small story and include people who understand its domain rules, implementation and testing.

Open the method guide

Good to do first

Paper illustration of a horizontal story map with an activity backbone, task cards below it and a cross-map release line.

Product Discovery

User Story Mapping

Supplies the selected story that Example Mapping then clarifies in detail.

Where to go next?

Agile

Specification by Example

Turns the collected rules and examples into executable specifications.

Agile

Story Splitting

Uses a story flagged as too large as the trigger for splitting it.

Deep dive

Purpose

When a story carries business rules and exceptions, it brings clarity before implementation. It makes examples, open questions, and boundaries visible enough that the logic becomes jointly sound.

How it works

It places rules and concrete examples side by side and checks where behavior is clear or contradictory. This makes acceptance criteria more precise and surfaces misunderstandings earlier.

In detail

Example Mapping works because rules only become reliable once they are checked against concrete cases and exceptions get their place. Good facilitation keeps the discussion tightly bound to observable examples and leaves questions open until their relevance is clear. This shrinks the room for interpretation in stories without letting the team slide into premature detail planning.

Facilitation

Bring a story with recognizable business logic and at least one edge case so the conversation has substance right away. The key moment comes when an example breaks a rule that seemed clear. Close with a few precise rules, open questions for later clarification, and a result that can feed directly into implementation.

The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.

Open method guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics

Behavior-Driven Development Requirements Examples Refinement

Sources

Example Mapping | Cucumbercucumber.ioPrimary source for the pre-implementation conversation, story/rule/example/question cards and stopping when scope is clear or time runs out.

In playbooks

Create Backlog ReadinessMove from rough ideas to shippable stories with examples, acceptance criteria, and estimation.

Artifact templates

Example Mapping: WorksheetPlan a focused conversation around one story, including decision ownership and follow-up.

markdown

example-mapping-working-template.md

Plan a focused conversation around one story, including decision ownership and follow-up.

Example Mapping: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Clarify one story together Time: About 25 minutes per story

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

Materials: One story card, blue rule cards, green example cards, red questions and pens or a digital board. Colors are a convention, not a requirement.
Roles: A small cross-functional group with product or domain ownership, engineering and testing. One person facilitates and keeps the map legible.
Advance information: Prepare the story, goal and known domain context. Mark prior beliefs and assumptions explicitly.
Overall time needed: About 25 minutes per focused story; split oversized stories and schedule follow-up when rules or questions are extensive.
Setup: Place the story at the top. Agree on how to mark stories, rules, examples and questions. Keep the conversation grounded in concrete cases.

Prepare for the work steps

Focus: Focus one story

Selected user story
Goal and context of the change

Rules: Elicit business rules

Focused story
Domain or product perspective

Examples: Explore rules with examples

Rule cards
Product, engineering and testing perspectives

Questions: Capture questions and next steps

Story, rules and examples
Decision makers or domain owners