5. Peace Corp Recruitment and Public Affairs
Story of how we used technology to
improve Peace Corp recruitment.
Switch from USPS to email
Switch from manual data entry to wild-card
search in gopher email system and screen
scraping results, an early for of ETL.
Conduct direct email campaigns when spam
still meant ‘meat in a can’
kburns@sagesw.com, @kevinbburns 5
7. How is value determined?
• Is value determined by delivery on
time, on budget, and on scope?
• Are your features delighting your
customers?
• Is all scope created equal?
• How do you know the value of the
scope?
kburns@sagesw.com, @kevinbburns 7
8. In a survey of 4 products, 65% of the features were rarely or never used.
How much money could have been
saved if we never built them?
In the Waterfall project world, we have to ask
for everything we can think of because capital
will end at the end of the project. Instead we
should be asking what has the most value in
terms of the business outcome and/or impact
and how are we going to measure it.
kburns@sagesw.com, @kevinbburns 8
9. Traditional Process
Schedule / CadenceTeam / CostRequirements
Schedule / Waterfall Features
Agile Approach
Team / Cost
Stabilize
Variable
kburns@sagesw.com, @kevinbburns 9
13. Do we all have
the same
understanding?
How do we
know?
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 13
14. Stop trying to write perfect
documents
Good documents are like
vacation photos
Document to help remember
Take a picture of your work to
help remember
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 14
15. Your job isn’t to write
better docs, it’s to
change the world.
Can you turn your
work into a Vocation?
kburns@sagesw.com, @kevinbburns 15
16. Stories create Understanding
• Stories aren’t a written form of requirements; telling stories through
collaboration with words and pictures is a mechanism that builds
shared understanding.
• Stories aren’t the requirements; they’re discussions about solving
problems for our organization, our customers, and our users that lead
to agreements on what to build.
• Your job isn’t to build more software faster: it’s to maximize the
outcome and impact you get from what you choose to build.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 16
17. Focus on User Interactions
Story mapping keeps us
focused on users and
their experience, and
the result is a better
conversation, and
ultimately a better
product.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
Good story conversations are about who
and why, not just what.
kburns@sagesw.com, @kevinbburns 17
18. Where to start?
• There’s always more to build than you have people, time, or money for.
• The goal shouldn’t be to implement everything we can think of, rather
what is the minimal amount we should implement to achieve desired
impact.
• Start with the most important user/customer.
• Map for a product release across multiple teams to visualize
dependencies.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 18
19. Story Mapping Mechanics
• Mapping your story helps you find holes in your thinking.
• Map only what you need to support your conversation.
• Reorganizing cards together allows you to communicate without saying
a word.
• Focus on the breadth of the story before diving into the depth.
• Use short verb phrases to capture what the user wants to do.
• Scope doesn’t creep; understanding grows.
• Focus on what you hope will happen outside the system to make
decisions about what’s inside the system.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 19
20. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 20
21. Release slicing (roadmap) – MVP for release?
Don’t Prioritize Features
Prioritize Outcomes
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 21
22. Minimum Viable Product (MVP) defined
• The minimum viable product is the smallest product release that
successfully achieves its desired outcomes.
• Minimum is a subjective term. So be specific about who it’s subjective to—
because it’s not you. Be specific about who your customers and users are,
and what they need to accomplish. What’s minimum to them?
• The minimum viable solution is the smallest solution release that
successfully achieves its desired outcomes.
• A minimal viable product is also the smallest thing you could create or do
to prove or disprove an assumption. Eric Reis – Lean Startup
• Minimum viable product experiment
• Minimum valuable solution/product
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 22
23. What’s the Opportunity?
• What is the big idea?
• Who are the customers?
• Who are the users?
• Why would they want it?
• What problems would it solve for customers and users that they
couldn’t solve today?
• What benefit would they get from buying and using it?
• Why are we building it?
• If we build this product and it’s successful, how does that help us?
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 23
24. Test your assumptions and hypothesis
• Validate that the problems you’re solving really exist.
• Prototype and test with users to learn whether your solution is
valuable and usable.
• Users want more than they use. (50-80% more)
• Build > Measure > Learn, rinse and repeat
• Development Partners (from the business) help validate your
assumptions and hypothesis
• Iterate until Viable/Valuable is achieved
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 24
25. Bad Release
Strategy
Good Release
Strategy
Treat every release as an experiment and be mindful of
what you want to learn.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 25
26. User Story Mechanics
• User tasks are the basic building blocks of a story map.
• Use the goal-level concept to help you aggregate small tasks or decompose
large tasks.
• Maps are organized left-to-right using a narrative flow: the order in which
you’d tell the story.
• Details, alternatives, variations, and exceptions fill in the body of a map.
“What about…?”
• Activities aggregate tasks directed at a common goal.
• Activities and high-level tasks form the backbone of a story map.
• Use slices to identify all the tasks and details relevant to a specific
outcome.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 26
27. User Story Mechanics Summary
• Tasks are short verb phrases that describe what people do.
• Tasks have different goal levels.
• Tasks in a map are arranged in a left-to-right narrative flow.
• The depth of a map contains variations and alternative tasks.
• Tasks are organized by activities across the top of the map.
• Activities form the backbone of the map.
• Slice map to identify tasks you’ll need to reach a specific outcome.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 27
28. 6 Steps to Story Mapping
1. Frame the problem
2. Map the big picture
3. Explore users and interactions
4. Slice out a release strategy
5. Slice out a learning strategy
6. Slice out a development strategy
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 28
29. More on Why
• We can both read the same document, but have a different
understanding of it.
• Kent Beck’s simple idea was to stop trying to writing the perfect
document, and to get together to tell stories.
• Stories get their name from how they’re supposed to be used, not from
what you’re trying to write them.
• If you’re not getting together to have rich discussions about your stories,
then you’re not really using stories.
• The best solutions come from collaboration between the people with the
problems to solve and the people who can solve them.
• Story conversations are about working together to arrive at the best
solution to a problem we both understand.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 29
30. Ron Jeffries 3 Cs from Extreme Programming Installed
Card: Write what you’d
like to see in the
software on index cards.
Conversation: Have a
rich conversation about
what to build.
Confirmation: Agree on
how you’ll confirm
definition of done.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 30
31. Story card attributes
• Title (name)
• Description (Who, What, Why)
• Acceptance Criteria (Definition of Done)
• Story number
• Estimate, size, or budget
• Value
• Metrics
• Dependencies
• Status
• Dates
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 31
32. Working remotely
• Use a document camera or web camera during a video conference to
let remote people see what’s being created on the wall.
• When collaborating remotely, use tools that allow everyone to see,
add to, and organize the model concurrently.
• Use tools to post pictures, videos, and text to help you retain and
remember your conversations.
• Use tools to sequence, track, and analyze progress.
• Handing off all the details about the story to someone else to build
doesn’t work. Don’t do that.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 32
33. For every story, there are two to follow. Alistair Cockburn
• In a traditional process, learning gets referred to as scope creep or
bad requirements.
• In an Agile process, learning is the purpose.
• Plan on learning from everything you build.
• Plan on being wrong at least half the time.
• Validated learning over working software (or comprehensive
documentation) Kent Beck
• Try using stories to drive the making of anything, whether it’s
software or not.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 33
34. Decompose
• If the story describes a solution that’s too expensive, consider a
different solution that helps you reach the goal.
• If the story describes a solution that’s affordable but big, break it into
smaller parts that allow you to evaluate and see progress sooner.
• Don’t break down big things into big plans. Break big things into small
things with small plans.
• You can deliver “half a baked cake, not a half-baked cake.”
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 34
35. Right-sizing
• A right-sized story from
a business perspective
is one that helps a
business achieve a
business outcome.
• A right-sized story from
a user’s perspective is
one that fulfills a need.
• A right-sized story from
a development team’s
perspective is one that
takes just a few days to
build and test.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 35
36. Conversations are one of the best tools for breaking
down big stories.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 36
37. Spike Stories
• From the Extreme Programming community
• Effort designed to learn
• Might not result in shippable code
• Should be timeboxed (<20hrs)
• Impacts team capacity
• Most teams don’t put story points on them until they know whether
or not it will become real work intended for release. (they don’t want
to inflate velocity for stuff that might not ship)
kburns@sagesw.com, @kevinbburns 37
38. MVP
Innovation
User
UX, BA, QA, SME
Business
Valuable
Design Usable
Software Engineering
AD, DD, DA
Business Customer
PO, SM, BL
Use scientific method
(measurable) to learn
and discovery your
Minimum Viable
(Valuable) Product
(MVP)
Technically
Feasible
MVP innovations emerge
from Conversations kburns@sagesw.com, @kevinbburns 38
39. INVEST in stories
•Independent – stand-alone
•Negotiable – there is more than one way to implement/solve
•Valuable – useful and ROI
•Estimable – we’re able to size it
•Small – deliverable within a few days
•Testable – can validate when done
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
kburns@sagesw.com, @kevinbburns 39
40. Define SMART story tasks
•Specific – discrete, known
•Measurable – testable, DoD
•Achievable – owner has skills to deliver it
•Relevant – needed to deliver story effectively
•Time-boxed – there is an understanding of duration
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
kburns@sagesw.com, @kevinbburns 40
41. Story writing options
This can work for System as user
• Given a certain precondition situation
• When a certain interaction occurs
• Then the system does this
An example:
• Given my bank account is in credit, and I made no withdrawals recently,
• When I attempt to withdraw an amount less than my card's limit,
• Then the withdrawal should complete without errors or warnings
http://martinfowler.com/bliki/GivenWhenThen.html
kburns@sagesw.com, @kevinbburns 41
42. Story Mapping Exercise Options
• Tasks when you wake-up in the morning
• Flight booking system
• Real scenario from work
kburns@sagesw.com, @kevinbburns 42
Traditional project management is very plan driven.
Agile is about starting with the schedule and cost then determining how much functionality can be delivered in that time for that amount of money.
Who are the companies we think would buy the product?
Who are the types of people inside those companies we think would use the product, and what would they be using it for?