Post on 05-Sep-2014
description
Building Better Backlogs withUser Story Mapping
comakershello@comakewith.uscomakewith.ustwitter: @comakewithus
3comakers, LLC :: hello@comakewith.us
Now and Later
3
Now and Later photo: Jay Malone via Flickr http://www.flickr.com/photos/jcorduroy/3725077603/
Turn and talk with
someone at your table:
What challenges do you
have today with user
stories?If you’re not working with
agile development, what
challenges do you have
with project requirements?
5comakers, LLC :: hello@comakewith.us
What we’ll cover
Stories and Story Maps
What’s a story map
Everything you need to know about stories, but were afraid to ask
Story Mapping in Agile Process
Building the backbone
Filling in and validating
Prioritizing and planning
7comakers, LLC :: hello@comakewith.us
A Story Map helps facilitate discussion about user’s experience with our product
Gary Levitt, owner & designer of Mad Mimi
7
details•smaller steps•alternative steps•UI details•technical details
workflow (from the user’s perspective)
backbone (gives structure to the map)
product goals(why build the product)
users(what are their goals)
8comakers, LLC :: hello@comakewith.us
Story maps aren’t an invention, they’re a pattern
David Hussman Story Jamming
Narrative Journey Map courtesy
Duncan Brown of the Caplin Group
Indi Young’s Mental Model
Todd ZakiWarfel’s Task Analysis Grid
9comakers, LLC :: hello@comakewith.us
Key conceptsSketch a quick image/diagram for each, based on what you remember
story map
backbone
other types of maps
10
2 comakers, LLC :: hello@comakewith.us
What you need to know about user
stories
11 comakers, LLC :: hello@comakewith.ushttp://www.cakewrecks.blogspot.com
Specifying in writing doesn’t work well
12comakers, LLC :: hello@comakewith.us
user
Stories facilitate a conversation with a goal of shared understanding
developer
13comakers, LLC :: hello@comakewith.us
Stories have a simple lifecycle
! ?Card
Conversation
!
Confirmation
Consequences
! ??!
Construction* Ron Jeffries coined the 3 C’s in Extreme
Programming Installed
14
BA
comakers, LLC :: hello@comakewith.us
user
testerPMUX Designer
Stories need to support lots of conversations across lots of project roles
developer
business leader
15comakers, LLC :: hello@comakewith.us
User Stories are boundary objectsHere’s the fine print on boundary objects:
“A boundary object is a concept in sociology to describe information used in different ways by different communities. They are plastic, interpreted differently across communities but with enough immutable content to maintain integrity” --Wikipedia
“They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.”
-- Leigh & Griesemer
17 comakers, LLC :: hello@comakewith.us
First we need to agree on why we’re here
Our job is to change the world
really, I’m not kidding
19© 2011 Jeff Patton, all rights reserved, www.AgileProductDesign.com
Agile stories are about the future world we imagine
As aI wantso that
20comakers, LLC :: hello@comakewith.us
Imagine the futureWho are the users and what benefit do they get?
What will users do in the future using your software?
Why should your organization build the software? What benefit will they get?
21comakers, LLC :: hello@comakewith.us
Stories gain detail over time and from conversation - don’t add all your details at onceStart with a short titleAdd a concise description some use this useful template:
As a [type of user] I want to [perform some task] so that I can [reach some
goal]
Add other relevant notes, specifications, or sketches
Before building software write acceptance criteria (how do we know when we’re done?)
That story’s too big!
Stories should describe software that can be built in a couple days
I’m not really getting
what this product is
about!When considering a product a story at a time it’s easy to lose the big picture
24comakers, LLC :: hello@comakewith.us
There’s no right size for stories for all conversations
25comakers, LLC :: hello@comakewith.us
user
productmanager
The natural “unit of measure” for stories varies by conversation
BA orUI Designer
developer
businessleader
release cycle
development cycle
User Stories shrink in size and grow in detail as they travel through a pipelineCapabilities or features•Name•Target customer or user•Value
Release-sized stories•Target release•Relative size•UI sketches•Rough acceptance tests
Stories for upcoming iterations•Priority•UI design•Business rules•Acceptance tests
Iteration-sized stories•Detailed acceptance tests•Small enough to complete in an iteration
Working tested software•Meets the team’s definition of done
Validated product parts•Vetted with customers and users•Evaluated for release readiness
Minimal releasable software•Generates value from its use
release cycle
development cycle
User Stories shrink in size and grow in detail as they travel through a pipeline
release cycle
development cycle
User Stories shrink in size and grow in detail as they travel through a pipeline
Just-in-time Refinement
Continuous Integration
29comakers, LLC :: hello@comakewith.us
Key conceptsAsk someone to explain the one that stands out the most for them, then switch and have them ask you.
agile user story
boundary object
output, outcome, & impact
the canonical story template
what, who, why
story size
the story funnel
30comakers, LLC :: hello@comakewith.us
Story maps are built during a product discovery phase
what:who:why:
what:who:why:
User Story Map
R1
User Story Map
R2
R3
Opportunity BacklogContains valuable product and feature ideas
Product Discovery Research, explore, validate and plan delivery of potential product solutions
Product Delivery Iteratively and incrementally build and validate product solutions
what:who:why:
R2what:who:why:
R3what:who:why:
R1
User Story Map Product Backlog
Product Goals
Simple Personas
User Interface Sketch
32comakers, LLC :: hello@comakewith.us
Before mapping identify relevant context
Business Strategy
Customer Segments
Users & user goals
Product usages
Regulatory constraints
Legacy product and architecture
?What else?
33comakers, LLC :: hello@comakewith.us
What, who, and why
What: name the product, feature, or capability you’re thinking of
Who: name the choosers and users who will buy and use the resulting solution
Why: say how the organization paying to build the software benefits - describes pains today or desired outcomes
Collaboratively sketch simple pragmatic personas
Stickyminds.com article: Pragmatic Personas
http://www.stickyminds.com/s.asp?F=S15793_COL_2
Identify measurable product goalshttp://agileproductdesign.com/writing/patton_ambiguous_business_value.pdf
34 comakers, LLC :: hello@comakewith.us
Build the backbone of your map by:
1. Discussing experience and then mapping
35comakers, LLC :: hello@comakewith.us
Building a backlog as a story map is a discussion about user experience, not user stories
36 comakers, LLC :: hello@comakewith.us
Build the backbone of your map by:
2. Brainstorming user’s tasks then organizing
(Ask a group of users to list all the things they do as part of a
business process)
38 comakers, LLC :: hello@comakewith.us
Build the backbone of your map by:
3. Researching, observing, designing, and then extracting
stories from a narrative(A narrative like a use case or user scenario describes what people do to reach their goals. Extract the verb
phrases from a narrative)
39comakers, LLC :: hello@comakewith.us
Harvest tasks from scenarios
Field Manager enters daily performance reports The shift has just ended and his reps are coming up with their totals.
They have printed sheets with totals written on them. Steve quickly looks them over and signs them off. His assistant manager brings him other sheets with totals he’s signed off.
In between visits by reps, Steve opens his Field Manager Workbench on his laptop. After logging in he sees today’s date and the planned number of applications his reps should be gathering – 180 for today.
He also sees yesterday’s numbers, and last week’s numbers, and the last 30 days in graph that shows applications relative to approval rate. Last week’s numbers were bad, and it’s the last week of the month, so Steve knows he’s got to do well today.
Steve clicks “enter rep performance data.” He shuffles his reps performance sheets and grabs the first one.
5. The date is defaulted to today, and the shift is defaulted to ‘morning’ since he hasn’t yet entered info for today. Steve begins to enter the reps name, but after a few characters the system auto-completes his name.
6. The rep’s ID is already filled in, along with the code for the credit card promotion they’re working on today.
7. Steve fills in the shift information for his rep. He then enters the total number of applications taken.
8. It looks like from the notes on this sheet that this rep left sick two hours early. Steve adds a note about this in the system.
9. Time passes as more reps bring in their sheets and Steve completes entering them in between conversations.
10. After all the sheets are done, Steve looks at a summary screen for the day. It looks like he’s close to his goal. If the next shift continues at this rate he’ll beat the plan by 5% or so. That’s good.
11. Steve validates that the base pay is correct at $5 per app, and that he’s set an individual bonus giving reps $50 each if they reach 20 apps. Next to each rep he sees the calculated pay, base, bonus, and total pay for the day.
12. The annual sale at Macy’s has brought a lot of people in today. Steve chooses a “sale increases mall foot traffic” code to add to his shift data sheet. Frank, his boss, has pestered him to make sure he includes this type of information in his daily summaries.
StevenCredit Card Marketing Field
ManagerSteven is a field manager
working at the local shopping center. He’s in the middle of a long workday supervising 13 reps who are busy talking to people trying to convince them to apply for a credit card.
40comakers, LLC :: hello@comakewith.us
A narrative imagines the experience of a product that doesn’t yet exist
UI Storyboard from Margarete Fuss, SAP AG
41comakers, LLC :: hello@comakewith.us
Story map under a story board
Photo courtesy of Carbonite, Boston, MA
41
42 comakers, LLC :: hello@comakewith.us
Think: “mile wide inch deep”
or “breadth not depth”
You’re trying to get the big picture
43comakers, LLC :: hello@comakewith.us
Key conceptsThink and write your own definitions in, based on what you remember
product context
pragmatic persona
measurable product goal
building the backbone
mile-wide inch-deep
45 comakers, LLC :: hello@comakewith.us
Discuss, fill in, refine the map, and test for
completeness
46comakers, LLC :: hello@comakewith.us
Discussions over story maps help drive out more details
Repeated review of the story map with multiple users and subject matter experts will help test the model for completeness
47
add, rewrite, split, combine, reorganize
comakers, LLC :: hello@comakewith.us
Play “wouldn’t it be cool if...”Look for variations What else might users of the system have done?
Look for exceptions What could go wrong, and what would the user have to do to recover?
Consider other users What might other types of users do to reach their goals?
Add in other product details Description of proposed UI Business rules Data elements
48comakers, LLC :: hello@comakewith.us
Key conceptsStand and stretch. One person will explain a concept while doing a simple stretch. The rest of the group will copy the stretch.
filling-in through discussion
variations
exceptions
idea
details
other user types
49
5 comakers, LLC :: hello@comakewith.us
Planning incremental product releases
50 comakers, LLC :: hello@comakewith.us
Prioritize stories vertically then “slice” to small
valuable releases
51comakers, LLC :: hello@comakewith.us
Adding tape lines to the wall lets participants organize stories into layers
51
52comakers, LLC :: hello@comakewith.us
Maps have latitude and longitude
52
sequence (time from the user’s perspective)
priority
(time from the planner and builder’s perspective)
53comakers, LLC :: hello@comakewith.us
Planning incremental releases can be a whole team event
53
54comakers, LLC :: hello@comakewith.us
Releases target business outcomes, customer, and user segments
* Menlo Innovations organizes personas into a target to help focus releases
55comakers, LLC :: hello@comakewith.us
Use target personas to drive release strategyTarget a primary persona for a first releaseTry a “good-better-best” strategy
56comakers, LLC :: hello@comakewith.us
Minimal Viable Releases target success for a product with a specific target audienceMVP: Minimal Viable ProductMMF: Minimal Marketable FeatureTo thin a release, first reduce the size of your target market
MVP
1 or more MMFs
57comakers, LLC :: hello@comakewith.us
You’ll spend most of your time filling in and validating
58comakers, LLC :: hello@comakewith.us
Key conceptsPop-up and explain a part of the concept. When finished sit down so that someone else can pop-up and explain. We’ll count how many we get in 3 minutes.
slicing the map
collaborative planning
MVP & MMF
release strategy
discovery phase
features and story maps
59
6 comakers, LLC :: hello@comakewith.us
Mapping experience(you already know this stuff)
60comakers, LLC :: hello@comakewith.us
Learn by mapping an experience you know
61comakers, LLC :: hello@comakewith.us
Use this simple warm up to show everyone they already know how to map
Step 1 - Brainstorm: List all the things you did to get ready to be here today
Starting from the moment you woke up until you arrived here
Using sticky notes, write the things you did, one thing per sticky note
62comakers, LLC :: hello@comakewith.us
Play along and quickly list all the things you did to get
ready this morning...
63comakers, LLC :: hello@comakewith.us
We naturally think in tasks
64comakers, LLC :: hello@comakewith.us
There’s a natural “human size” for tasks
* Cockburn’s Writing Effective Use Cases describes goal levels for use cases this way
65comakers, LLC :: hello@comakewith.us
In small groups, organize your stickies into chronological order - the order things were done - from left to right
You’ll merge your different timelines into a single timeline
Stack identical stickies (similar things done at similar times
Place parts of things under larger things (“wash hair” might go under “take shower”)
Step 2: Organize
66comakers, LLC :: hello@comakewith.us
The exercise looks like this
66
67comakers, LLC :: hello@comakewith.us
People naturally build a two-dimensional map
67
sub-tasks, alternatives, variations, and details
An imperfect narrative flow
68comakers, LLC :: hello@comakewith.us
In your same groups, look for groups of stickies that seem to go together and create a higher-level label for those
All the stuff done in the bathroom could be called “bathing” and all the stuff done in the kitchen might be “getting breakfast.”
You may need to invent some names - what would you call those things you do to get out of the door? Gathering laptop, papers, car keys...
Step 3: Find Patterns
69comakers, LLC :: hello@comakewith.us
We naturally group tasks into activities
70comakers, LLC :: hello@comakewith.us
Look back across the model of the whole experience. What was your favorite part of the morning, your high
point? Write the high point down on a sticky with a smiley face. Stick it where you think it goes on the map.
What part of the morning did you hate? Frustrated you? Write a note about it with a frowny face. Stick it where you think it goes on the map.
Step 4: Mark high points and pains
71comakers, LLC :: hello@comakewith.us
Experience maps describe the world today
71
* Narrative Journey Map courtesy Duncan Brown of
the Caplin Group
72comakers, LLC :: hello@comakewith.us
Experience maps describe the world today
72
* Narrative Journey Map courtesy Duncan Brown of
the Caplin Group
73comakers, LLC :: hello@comakewith.us
The biggest benefit of modeling this way is not the
data in the model
74comakers, LLC :: hello@comakewith.us
Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
75comakers, LLC :: hello@comakewith.us
Representing our ideas as models allows us to detect inconsistencies in our understanding
76comakers, LLC :: hello@comakewith.us
Through discussion and iterative model building we arrive at a stronger shared understanding
77comakers, LLC :: hello@comakewith.us
Using that shared understanding we can work together to arrive at the same objectives
78comakers, LLC :: hello@comakewith.us
Shared understanding is critical to successful collaborative work
79comakers, LLC :: hello@comakewith.us
Model collaboratively to build shared
understanding
80comakers, LLC :: hello@comakewith.us
Key conceptsWrite your own definitions in, based on what you remember
user tasks
goal-task-tool dependency
task goal level
user activity
experience map
journey map
collaborative modeling
81comakers, LLC :: hello@comakewith.us
Now and Later
81
Now and Later photo: Jay Malone via Flickr http://www.flickr.com/photos/jcorduroy/3725077603/
What challenges do you
have today with user
stories?If you’re not working with
agile development, what
challenges do you have
with project requirements?
What will you change about what you’re doing based on what you’ve heard?
82comakers, LLC :: hello@comakewith.us
Building Better Backlogs withUser Story Mapping
Thank you!Thank you!comakershello@comakewith.uscomakewith.ustwitter: @comakewithus