Method guideAgile

Example Mapping

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityLow

Time30-60 min

Participants3-7

FormatWorkshop

MaturityEstablished

Plan the session

Prerequisite

What needs to be finished first

Complete firstFocused story

One story describes a bounded business change and its intended value.

Oversized or unclear stories need discovery or splitting first.

Complete firstRelevant perspectives

Domain decisions, implementation and testing can be discussed together.

Missing decision authority creates open questions for follow-up.

Preparation

What needs to be ready before start

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.

People / roles

A small cross-functional group with product or domain ownership, engineering and testing. One person facilitates and keeps the map legible.

Pre-read

Prepare the story, goal and known domain context. Mark prior beliefs and assumptions explicitly.

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.

Core question

The one question this method answers

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

Flow

Phases with goal, actions, output and pitfall

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.

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

1
Focus
Focus one story
Goal
Everyone discusses the same intended behavior.
Inputs for this step
- Selected user story
- Goal and context of the change
Actions
- Read the story together and clarify actor, trigger and intended value.
- Place the story visibly at the top and confirm the scope for the conversation.
Output
A focused story with a shared context
Story · actor · intended change
Quality check
Is the story small enough for a short clarification?
Pitfall
The story bundles several independently testable changes. Split the story or do discovery first; leave the unresolved scope out of this session.
Timing: About 5 minutes.
2
Rules
Elicit business rules
Goal
The group states verifiable rules instead of jumping to solutions.
Inputs for this step
- Focused story
- Domain or product perspective
Actions
- Gather known acceptance criteria and domain constraints.
- Write each concise, independent rule on a blue card.
- Clarify terms and boundary cases together.
Output
Rule cards for the story
One rule per card · unambiguous condition
Quality check
Is each rule clear and testable?
Pitfall
The group records vague wishes or UI ideas as rules. Phrase rules as observable behavior and mark solution ideas separately.
Timing: About 8 minutes.
3
Examples
Explore rules with examples
Goal
Examples expose boundaries, exceptions and testing needs.
Inputs for this step
- Rule cards
- Product, engineering and testing perspectives
Actions
- Find a concrete example for each rule with a precondition, event and expected result.
- Add counterexamples and relevant edge cases.
- Place green examples under the rule they illustrate; Gherkin is optional.
Output
Rules with examples and counterexamples
Given · when · expected result
Quality check
Do the examples clarify the rule rather than merely restating it?
Pitfall
Examples remain hypothetical or cover only the happy path. Name a source for real cases when available; discuss at least one relevant counterexample.
Timing: About 12 minutes.
4
Questions
Capture questions and next steps
Goal
The map shows whether the story is clarified, too large, or still depends on unresolved decisions.
Inputs for this step
- Story, rules and examples
- Decision makers or domain owners
Actions
- Mark unanswered questions in red and keep the conversation moving.
- Capture newly discovered or oversized stories as separate yellow stories.
- Assign an owner and date to open questions; then split, clarify or prepare the story for delivery.
Output
Example map and agreed next action
Rules · examples · open questions
Quality check
Are open questions assigned an owner and date? Is the story clear enough, or should it be split?
Pitfall
A full-looking board hides unresolved decisions. Keep open points explicit; update the rule, example or story split only after they are answered.
Timing: About 5 minutes.

Artifact

What comes out at the end

Sketch: what the artifact looks like

Example Mapping · Matt WynneEine Story über Regeln, konkrete Beispiele und offene Fragen schnell klären

Form

A versioned example map with one story, rules, examples and counterexamples, open questions and linked acceptance tests.

Versioning / ownership

Record the story ID, date and participants. Track rule changes; preserve answered questions with the decision and its source.

Tool alternatives

Four card colors or equivalent digital labels
Board with story, rule, example and question cards
Use Gherkin only where concrete acceptance tests benefit from it

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

Example Map

Story · yellow

Which single change are we clarifying?

...

Rules · blue

Which general business condition applies?

...

Examples · green

Which concrete precondition, action and outcome illustrate the rule?

...

Questions · red

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

...

Blank worksheet: keep story, rules, examples and questions distinct. Record examples as concrete cases; assign an owner and date to unanswered questions.

Source: Cucumber

Focus: Focus one story

Expected artifact: A focused story with a shared context

Story · actor · intended change

Entry:

...

Is the story small enough for a short clarification?

Rules: Elicit business rules

Expected artifact: Rule cards for the story

One rule per card · unambiguous condition

Entry:

...

Is each rule clear and testable?

Examples: Explore rules with examples

Expected artifact: Rules with examples and counterexamples

Given · when · expected result

Entry:

...

Do the examples clarify the rule rather than merely restating it?

Questions: Capture questions and next steps

Expected artifact: Example map and agreed next action

Rules · examples · open questions

Entry:

...

Are open questions assigned an owner and date?
Is the story clear enough, or should it be split?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/example-mapping/run-sheet

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

example-mapping-beispiel.md

Concrete filled scenario, fictional example

Fictional teaching example: Reserve a tool

All details are invented; no research was conducted.

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

Rule R1 (blue): A confirmed reservation states the tool and collection time.

Example F1 (green): A person reserves on Monday for Wednesday. The confirmation names the tool and Wednesday as the collection day.

Rule R2 (blue): If the tool is unavailable in the requested window, no reservation is confirmed.

Example F2 (green): The tool is already booked for Wednesday. The system reports unavailability and confirms no reservation.

Question (red): What happens if the previous loan ends late? In this fictional session, Alex owns clarification by Friday.

Next step: Update the rule and tests after a domain decision. Fictional example cards do not provide real user evidence or establish demand.

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

Focus one storyThe story bundles several independently testable changes.View in phase
Elicit business rulesThe group records vague wishes or UI ideas as rules.View in phase
Explore rules with examplesExamples remain hypothetical or cover only the happy path.View in phase
Capture questions and next stepsA full-looking board hides unresolved decisions.View in phase

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The story contains independently deliverable behaviors: split it before continuing.

A domain question requires evidence or an external decision: capture it in red and assign an owner and date.

Many rules or questions remain after about 25 minutes: treat this as a complexity signal, split the story or add discovery.

A quantitative frequency matters: add an appropriate data source or study.

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.

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

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profile More methods