Motivation
Matt Wynne, Cucumber, 2015
- Before you pull a user story into development, it’s crucial to have a conversation to clarify and confirm the acceptance criteria.
- Whatever you call this conversation, many teams find it hard; it’s unstructured, it takes too long and gets boring. The result is they don’t do it regularly or consistently, or maybe they just give up on it entirely.
- I’ve discovered a simple, low-tech method for making this conversation short and powerfully productive. I call it Example Mapping.
How it works
- We start by writing the story under discussion on a yellow card and placing it at the top.
- Next, we write each of the acceptance criteria, or rules that we already know, on a blue card and placing those beneath the yellow story card.
- For each rule, we may need one or more examples to illustrate it. We write those on a green card and place them under the relevant rule.
- As we discuss these examples, we may uncover questions that nobody in the room can answer. We capture those on a red card and move on with the conversation.
- We keep going until the group is satisfied that the scope of the story is clear, or we run out of time.
Timeboxed
- A small group of amigos should be able to map out a well-understood, well-sized story in about 25 minutes.
Instant Feedback
- A table covered in red question cards tells us that we still have a lot to learn about this story.
- A table covered in blue rule cards tells us that this story is big and complicated. Perhaps we can slice it? Take another yellow (story) card and put the sliced story on the backlog.
- A rule with many green examples might be over-complex. Are there multiple rules at play that need to be teased apart?
Example
Rules = Requirements?
Rules may or may not map to requiremts. When writing requirements to late in the process, changes to rules may apply.
Further hurdles with Example Mapping
