The document discusses the importance of building shared understanding through example mapping in software development, emphasizing the value of different perspectives, such as user story development, testing, and business. It outlines when to engage in these conversations, particularly just-in-time before sprints, and includes structured conversation outputs like refined acceptance criteria and empathy building. Key recommendations include discussing examples to promote understanding and utilizing collaborative modeling and acceptance criteria.

1. How to build shared understanding with
example mapping
Kent J. McDonald
kent@kbp.media
@kbpmedia

2. Why talk about
examples?
2

3. Why talk about examples?
BUILD SHARED
UNDERSTANDING
OF THE STORY
IDENTIFY AND
ANSWER
QUESTIONS TO
MINIMIZE
INTERUPTSDURING DELIVERY
GIVE TEAM A
JUMP START ON
TEST PLANNING
AND TESTING
INVOLVE
DIFFERENT
PERSPECTIVES
FOR A BETTER
RESULT
IDENTIFY AND
DISCUSS
ASSUMPTIONS
PROVIDE CLEARPICTURE OFBUSINESS INTENT
3

4. Who should be
included?
4

5. (At Least) Three Perspectives
USER
STORY
DEVELOPMENT
TESTING
BUSINESS
DO I HAVE
ENOUGH
INFO TO
SOLVE THIS
PROBLEM?
HAVE I
DESCRIBED
THE
PROBLEM I
WANT
SOLVED?
WHAT
HAPPENS
WHEN…
THE “THREE AMIGOS” 5

6. When should we
have these
conversations?
6

7. Just in Time
BY END OF SPRINT N, HAVE
ENOUGH STORIES DESCRIBED
FOR SPRINT N+1
USER STORIES FLOW
AS THEY ARE DESCRIBED (READY)
7

8. Discovery Board
POLICY:
USER STORY
POLICY:
• USER STORY
• (SOME)
ACCEPTANCE
CRITERIA
• SIZE
POLICY:
• USER STORY
• ACCEPTANCE
CRITERIA
• SIZE
• MOCKUPS
• EXAMPLES
• DEPENDENCIES
• STAKEHOLDER
POLICY:
• USER STORY
• (SOME)
ACCEPTANCE
CRITERIA
8
Getting things ready to rock is a great
time for these conversations

9. How do we
structure these
conversations?
9

10. Example Mapping
Outputs:
§ Examples
§ Refined rules/acceptance criteria
§ New/split stories
§ Shared understanding
§ Empathy
10
STORY RULE(ACCEPTANCECRITERIA)
QUESTION
(WHAT IF…)
EXAMPLE(THE ONEWHERE…)
https://speakerdeck.com/mattwynne/example-mapping
Y
R
B
G

11. STORY
RULE RULE RULE
QUESTION
EXAMPLE
RULE
QUESTION
EXAMPLE
EXAMPLE
EXAMPLE
EXAMPLE
Example
Mapping
11

12. Add a
Review
Can only
review
sessions in
own track
Can only
review a
session
once
Can’t
review
your own
session
What if
session
changes
tracks?
What if
reviewer is
added to
session as
co-
presenter?
The one
where
session is in
Reed’s track
The one
where
session is
not in Reed’s
track
The one
where Reed
is presenter
The one
where Reed
is co-
presenter
Example
Mapping – An
Example
12

13. What do we use
to remember
what we said?
13

14. Collaborative Modeling
14
AS REED
I CAN ADD A
REVIEW TO A
SESSION
SO THAT I CAN
PROVIDE
FEEDBACK TO
SAM

15. Sample Models
PROCESS FLOW
UI PROTOTYPE
REPORT MOCKUP 15

16. Acceptance Criteria
16
§ REVIEWERS MUST PROVIDE A TITLE
AND DESCRIPTION FOR THE REVIEW.
§ REVIEWERS MAY INDICATE WHETHER
THEY THINK THE SESSION SHOULD BE
INCLUDED IN THE PROGRAM.
§ REVIEWERS MAY PROVIDE DETAILS OF
ANY CONFLICTS OF INTEREST THEY
HAVE IN REVIEWING THE SESSION.
§ REVIEWERS MAY PROVIDE COMMENTS
FOR THE REVIEW COMMITTEE.
§ SUBMITTERS OF THE REVIEWED
SESSION CAN SEE ONLY THE TITLE
AND DESCRIPTION OF THE REVIEW.
§ SUBMITTERS MAY SEE ONLY
REVIEWS OF SESSIONS THAT THEY
HAVE SUBMITTED.
§ REVIEWERS MAY REVIEW ONLY
SESSIONS SUBMITTED TO TRACKS
ON WHICH THEY ARE REVIEWERS.
§ REVIEWERS MAY NOT REVIEW ANY
SESSION ON WHICH THEY ARE
PRESENTERS OR CO-PRESENTERS.
§ REVIEWERS MAY PROVIDE ONLY
ONE REVIEW FOR A SESSION.
§ THE TITLE OF THE REVIEW MUST
CONTAIN 95 CHARACTERS OR LESS.
As Reed
I can add a
review to a
session
So that I can
provide feedback
to Sam

17. Examples
17
AS REED
I CAN ADD A
REVIEW TO A
SESSION
SO THAT I CAN
PROVIDE
FEEDBACK TO
SAM

18. Questions?
18

19. If you remember nothing else….
DISCUSSING
EXAMPLES
SPEEDS SHARED
UNDERSTANDING
DISCUSS
EXAMPLES
WHEN GETTINGSTORIES READY
INVOLVE
MULTIPLE
PERSPECTIVES
(THREE
AMIGOS)
USE MODELS,
ACCEPTANCE
CRITERIA, AND
EXAMPLES
19

20. Kent McDonald
kent@kbp.media
@kbpmedia
www.kbp.media