Story Writing & Mapping Techniques for Building the Right Product

Story Writing & Mapping
presented by
Kevin Burns
1-18-2017

Kevin Burns
Coach
Org Change Agent
kburns@sagesw.com, @kevinbburns 2

My work history and experience

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’

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?

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.

Traditional Process
Schedule / CadenceTeam / CostRequirements
Schedule / Waterfall Features
Agile Approach
Team / Cost
Stabilize
Variable

Jeff Patton

What do you see?
Seven Habits of Highly Effective People - Stephen Covey

Telephone
Game – Cake
Requirements

Do we all have
the same
understanding?
How do we
know?
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton

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

Your job isn’t to write
better docs, it’s to
change the world.
Can you turn your
work into a Vocation?

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.

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.
Good story conversations are about who
and why, not just what.

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.

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.

Release slicing (roadmap) – MVP for release?
Don’t Prioritize Features
Prioritize Outcomes

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

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?

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

Bad Release
Strategy
Good Release
Strategy
Treat every release as an experiment and be mindful of
what you want to learn.

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 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.

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

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.

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.

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

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.

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.

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.”

Right-sizing
• A right-sized story from
a business perspective
is one that helps a
business achieve a
business outcome.
a user’s perspective is
one that fulfills a need.
a development team’s
perspective is one that
takes just a few days to
build and test.

Conversations are one of the best tools for breaking
down big stories.

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)

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

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/

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/

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

Story Mapping Exercise Options
• Tasks when you wake-up in the morning
• Flight booking system
• Real scenario from work

?
kburns@sagesw.com
@kevinbburns
612-396-7724

Story Writing & Mapping Techniques for Building the Right Product

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (15)

Similar a Story Writing & Mapping Techniques for Building the Right Product

Similar a Story Writing & Mapping Techniques for Building the Right Product (20)

Más de DevJam

Más de DevJam (12)

Último

Último (20)

Story Writing & Mapping Techniques for Building the Right Product