Getting Acceptance Criteria right with Example Mapping
I already wrote about the concept of the Three Amigos, this time I want to share a method to facilitate the refinement of user stories and the creation of acceptance criteria, named Example Mapping.
The problem with getting user stories and acceptance criteria right is that often there is not enough collaboration - just remember the Agile Principle
"Business people and developers must work together daily throughout the project."
Example Mapping is an effective and playful way of solving this problem.
Rules vs. Examples
There are different ways to describe acceptance criteria, like rules or examples. While rules are generalizations and by this often broad and ambiguous, examples are specific and easy to understand. Often an underlying rule is not yet clear, while a single example is.
Example Mapping
The idea of Example Mapping is to create acceptance criteria for user stories by mapping examples to rules. By this, you generate better rules and in general, discover issues that are not yet addressed in the story. You write these issues down as questions, they can trigger new rules, or are simple a token for deferring the issue.
You need index cards with four colours. Each card corresponds to one of the artifacts mentioned above
Yellow ↔ Story
Blue ↔ Rule
Green ↔ Example
Red ↔ Question
Scenario: Parking price calculation
Imagine we were to design a machine that calculates the price of parking tickets at the airport. There could be different parking sites like
Valet parking
Short term parking
Long-term parking
with each site having its own set of rules how a ticket price is calculated.
When discussing the user story "as a user I want use valet parking in order to save time" (yellow card), the product owner would for example explain that the price is 6€ for the first hour (a blue card), with a maximum of 18€ per day (another blue card).
The first obvious example would be parking for 5 hours (green card), with a price of 6€, and a blue card for parking a little longer than five hours (another green card), with a price of 18€.
Maybe the amigos (most likely the tester) would address more edge cases, like daylight savings time or overnight parking. The product owner would realize that the story needed refinement: A red card indicating an unresolved question would be created. Then the amigos could improve the existing (or add new) rule and example cards.
Take a look at the photographs (german language):
Benefit
Example mapping enhances the shared understanding of user stories by refining them in collaboration.
The product owner no longer has to make the acceptance criteria up on his own, their quality increases, and developers and testers can estimate with more confidence.
The rules can be used as a guidance for an implementation, while the examples can be used as templates for test cases.
Writing on index cards and pinning them on a board is more fun than staring at a screen displaying an issue tracker, there is more interaction and exeryone is in an active state of mind.
Maybe try an Example Mapping session in one of your grooming sessions, and find out if it works for you!
Reference
Just read the blog post by Matt Wynne, the creator of Example Mapping, for a definitive introduction.