User Story Mapping

User Story Mapping

Author

Jeff Patton

Year
2014
image

Review

The author goes to great length to explain why stories and story maps are important (they help build a shared understanding in product teams). He makes it clear that the exact format and process for creating stories isn’t important - which is a common misconception among product managers.

I didn’t enjoy the authors use of examples and analogies and I found the venture into Product Discovery a little clunky. You can tell this book was written 7 years before Continuous Discovery Habits (which is a better framework for Product Discovery).

I’d recommend Product Managers User Story Mapping - it is a foundational and influential text. But it doesn’t make a great reference text- so I’d recommend creating your own 1 page version of ‘how to story map’ and ‘how to write user stories’.

You Might Also Like…

image

Key Takeaways

The 20% that gave me 80% of the value.

  • Shared documents ≠ Shared Understanding
  • The goal of story mapping is to create shared understanding
  • Build the right things (in the right way) so we can minimise output, and maximise outcome and impact.
  • Story Mapping helps…
    • find holes in your thinking, and think holistically across teams and dependencies
    • build a shared understanding with the team
    • tell the story of your customers end to end
    • think through alternative ways to getting to an outcome
  • ‘Talk and Doc’ is the process of writing to externalise your thinking as you tell stories to each other. Think → Write → Explain → Place.
  • Focus on the breadth of the story map before adding depth (mile wide, inch deep)
  • Anatomy of a Story Map
    • Backbone → shown at the top, the big things and little things that tell the story end to end.
    • Narrative flow → left to right order, that tells the story of the product being used.
    • Hierarchy between activities, steps and details
      • Activity → that people will use the software for
      • Steps → inside that bigger activity
      • Details → of the step above
    • Scope lines → divide your stories into meaningful releases
      • ‣
      Example Story Map
      image
  • Once you’ve covered the breadth (the end to end backbone) you can add surrounding detail
    • What are the specific things they’d do here?
    • What are alternative things they could do?
    • What would make it really cool?
    • What about when things go wrong?
  • Gather key information to the side of your map
    • Relevant context
    • Users
    • Ideas and product principles
    • Key Assumptions and Risks
    • Key research or experiments that could help
  • If you’re arguing where something goes - it likely doesn’t matter
  • 6 Step Story Mapping
    1. Frame the problem (who, why)
    2. Map the big picture (wide and shallow)
    3. Explore (go deeper, talk about edge cases)
    4. Slice out a release strategy
    5. Slice out a learning strategy
    6. Slice out a development strategy
  • Map only what you need to support your conversation
  • The minimum viable product is the smallest product release that successfully achieves its desired outcomes
  • Generic Value Slices: “See it work, Make it Better, Make it releasable”
  • By slicing large things into small things you get more opportunities to measure AND the more examples you have at a given size, the better you get at estimating them
  • Highlight stories you think are risky - as they’ll take more time from the team. Enables a risk burn down chart
  • Think about your opening, mid and endgame strategy:
    • Opening game → focus on essentials, focus on risky things, skip the edge cases, build just enough to get something working end to end
    • Middle game → fill in and round features. Add the edge cases. Start testing for things like performance, scalability and usability.
    • End game → Refine your release, make it sexier more efficient. Find improvement opportunities, test with real data. Get feedback from users.
  • Stories get their name for how they’re supposed be used - not written.
  • The Simple Story Template:
    • As a [type of user]
    • I want to [do something]
    • So that I can [get some benefit]
  • Don’t be a template zombie → it doesn’t need to be written in a template to be considered a story
  • A shorthand story template for sticky notes:
    • Who:
    • What:
    • Why:
  • Really talk about: who, what, why, what’s going on outside of the software, what goes wrong, questions and assumptions, better solutions, about how, and how long.
‣
Typical Story Card Information
  • Short title
  • Description (Who, What, Why)
  • Related Stories
  • Author
  • Date Created
  • Rough T-Shirt Size
  • Status (In Discovery)
  • Importance (high, medium, low)
  • Tracking System Number
  • Effective decision making goes best with groups of 2-5.
  • Don’t throw things over the fence, but don’t involve everyone in every conversation either.
  • When evaluating what was built be clear to separate the following (for everyone’s sanity) …
    1. Did we build what we agreed to build?
    2. If it’s what we agreed, now we see it, should we make some changes?
  • It’s not always software → validated learning over working software → stories can drive the making of anything (doesn’t have to be software)
  • Rule of thumb: break stories down into something that takes a couple of days to build and test
  • Epics tend to be the right size for the user and the business but not the development team.
  • Break stories down progressively and just in time
  • Don’t create huge maps to discuss a single feature - map only what you need to tell a story about your feature
  • Don’t have a single story writer
    • There are too many conversations for a single person to be involved in
    • One person doesn’t brain enough expertise and diversity to arrive at the best solution
‣
Consider using an Opportunity Canvas (from… Marty Cagan)
  • Users and Customers
  • Problems
  • Solutions today
  • Solution Ideas
  • How will users use your solution?
  • Adoption Strategy
  • User metrics
  • Business Challenges
  • Budget
  • Business Benefits and Metrics
‣
Actual Canvas
image
  • Don’t believe that your minimum viable solution will be successful. Expect 20% to work as expected, 20% to be genuine failures and everything else to fall in between
  • Improvements made after releases are the most valuable
image

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

The Power of Story Mapping

  • Shared documents ≠ Shared Understanding…which is why we need story mapping. People can read the same document and have a different understanding. Therefore we should stop trying to write perfect documents and start having conversations. Conversations are key to checking each others understanding.
  • Don’t think of stories as requirements → think of them as conversation starters. The goal of story mapping is to create shared understanding. Conversations with sketches and post-its create shared understanding.
  • If you want to change the world - you should care about outcomes not outputs. Agile measures velocity and looks to increase the rate of output. Building and shipping software isn’t the point. Instead measure what impact you’ve had on people’s lives. Good story conversations are about who and why, not just what . The goal is to choose to build the right things (in the right way) so we can minimise output, and maximise outcome and impact.
  • Story Mapping helps…
    • find holes in your thinking, and think holistically across teams and dependencies
    • build a shared understanding with the team
    • tell the story of your customers end to end
    • think through alternative ways to getting to an outcome (and prioritise an MVP). There’s always more to build that you have people, time or money for. Focusing on specific outcomes is the secret to prioritisation.

How to Story Map

  • ‘Talk and Doc’ is the process of writing to externalise your thinking as you tell stories to each other.
    • Think → Write → Explain → Place
  • Focus on the breadth of the story map before adding depth (mile wide, inch deep)
  • Story Mapping preserves the natural hierarchies and dimensions that happen when you start placing cards down. You tend to put things in narrative order, left to right. You tend to put important things at the top - and break things down underneath.
  • The Anatomy of a Story Map
    • Backbone → shown at the top, the big things and little things that tell the story end to end.
    • Narrative flow → left to right order, that tells the story of the product being used.
    • Hierarchy between activities, steps and details
      • Activity → that people will use the software for
      • Steps → inside that bigger activity
      • Details → of the step above
    • Scope lines → divide your stories into meaningful releases
    • Frame your idea → Why build it? What problems are you solving for the business and for customers? What outcomes are you trying to achieve?
    • Describe your customers and users → Write down different types of users? Can you focus on a single primary user?
  • Once you’ve covered the breadth (the end to end backbone) you can add surrounding detail
    • What are the specific things they’d do here?
    • What are alternative things they could do?
    • What would make it really cool?
    • What about when things go wrong?
  • Gather key information to the side of your map
    • Relevant context
    • Users
    • Ideas and product principles
    • Key Assumptions and Risks
    • Key research or experiments that could help
image
  • Tasks are short verb phrases that describe what people do (in order to reach a goal)
  • User tasks are the basic building blocks of a story map
  • Tasks have different goal levels. Take a hammer to a big task and it’ll break into smaller ones.
    • Summary Tasks: E.g. Get ready for work
    • Functional/Sea-Level Tasks: E.g.Take a shower
    • Sub-functional/Sub-Tasks: E.g. Wash hair
  • A sea-level task is one we’d expect to complete before stopping to do something else
  • Tasks in a the map are arranged in a left to right narrative flow - the order in which you’d tell the story
  • The depth (or body) of a map contains variations, alternatives, details and exceptions
  • Tasks are organised by activities. across the top of the map
  • Distill your map to make a backbone → Activities and high-level tasks form the backbone of a story map
  • You can slice the map to identify the tasks you’ll need to reach a specific outcome.
  • If you’re arguing where something goes - it likely doesn’t matter
  • Additional/Optional things to add to the map:
    • Pains
    • Joys/Rewards
    • Questions
    • Ideas
  • It’s hard to transition from talking about screens and features to short verb phrases
  • 6 Step Story Mapping
    1. Frame the problem (who, why)
    2. Map the big picture (wide and shallow)
    3. Explore (go deeper, talk about edge cases)
    4. Slice out a release strategy
    5. Slice out a learning strategy
    6. Slice out a development strategy
  • Key Best Practices:
    • Start the day with a product vision exercise (Elevator pitch or cover story format)
    • Then look at the typical users of the product
    • Define the user stories
      1. starting with high-level usage steps
      2. break them into activities per user role
      3. concrete user stores in the format of (as a <role>, I want <functionality> so that <value>
    • Colour code things by persona or role
    • Highlight areas where you need to do more research
    • Prioritise the stories once you have enough detail
  • Map only what you need to support your conversation
  • Ended up with too many cards?
    • it’s a sign of your understanding growing
    • it will naturally trigger prioritisation - do we need all of this?
  • Classifying features when competition is a top concern
    • Differentiator: a feature that sets you apart from the competition
    • Spoiler: a feature that is moving in on someone else’s differentiation
    • Cost reducer: a feature that reduces the organisation costs
    • Table stakes: a feature necessary to compete in the marketplace
  • MVP Definitions:
    • The minimum viable product is the smallest product release that successfully achieves its desired outcomes
    • Viable implies an organism that can survive in the world, on its own, without dying
    • You can swap ‘product’ for ‘solution’ to broaden people’s thinking

Mapping to Building: What to pick up first

  • The best estimates come from developers who really understand what they’re estimating
  • Generic Value Slices: “See it work, Make it Better, Make it releasable”
  • The more frequently you measure (story points and burn down), the better you get at predicting.
    • By slicing large things into small things you get more opportunities to measure AND the more examples you have at a given size, the better you get at estimating them
  • Highlight stories you think are risky - as they’ll take more time from the team. Enables a risk burn down chart
  • You need to balance iterative and incremental thinking:
    • Iterative thinking → evaluating and making changes to what you’ve made
    • Incremental thinking → working on new things, solving new problems
  • What stories should you pick up first?
    • Think about your opening, mid and endgame strategy:
    • Opening game → focus on essentials, focus on risky things, skip the edge cases, build just enough to get something working end to end
    • Middle game → fill in and round features. Add the edge cases. Start testing for things like performance, scalability and usability.
    • End game → Refine your release, make it sexier more efficient. Find improvement opportunities, test with real data. Get feedback from users.

Writing Stories

  • We can both read the same document but have a different understanding of it. You have to have rich discussions together about the stories. Stories get their name for how they’re supposed be used - not written.
  • The 3 C’s from Extreme Programming Installed → by Ron Jeffries
    • Card → write what you’d like to see in the software on index cards
    • Conversation → get together and have rich conversations about what to build
    • Confirmation → agree together how you’ll confirm that software is done
      • Acceptance Criteria:
        • If we build what we agree to, what will we check to see that we’re done?
        • How will demo this at the end of the sprint?
        • Use words and pictures → record your agreements as acceptance criteria
  • The Simple Story Template:
    • As a [type of user]
    • I want to [do something]
    • So that I can [get some benefit]
  • Don’t be a template zombie → it doesn’t need to be written in a template to be considered a story
  • A shorthand story template for sticky notes:
    • Who:
    • What:
    • Why:
  • Really talk about: who, what, why, what’s going on outside of the software, what goes wrong, questions and assumptions, better solutions, about how, and how long.
  • There are many different kinds of conversations, with different people for every story
  • Keep information alive → information radiators → big, visible information radiator to describe how big, visible information on the wall radiates useful stuff into the room
  • Typical Story Card Information:
    • Short title
    • Description (Who, What, Why)
    • Related Stories
    • Author
    • Date Created
    • Rough T-Shirt Size
    • Status (In Discovery)
    • Importance (high, medium, low)
    • Tracking System Number

There’s more to building a shared understanding to

  • Card → Conversation → Confirmation → Construction → Consequences
  • Don’t throw things over the fence, but don’t involve everyone in every conversation either.
  • Effective decision making goes best with groups of 2-5.
  • Inspect the results of your work:
    • User Experience Quality → easy, fun, simple, attractive, on brand?
    • Functional Quality → bugs, errors
    • Code Quality → standards, extendable, maintainable, scalable
  • Separate your concerns for everyone’s sanity…
    1. Did we build what we agreed to build?
    2. If it’s what we agreed, now we see it, should we make some changes?
  • It can be good practice to write a second story (for each story) to remind yourself you’ll have to iterate on it later to achieve the outcome you want. Remember learning is the purpose and shouldn’t be considered part of scope creep.
  • It’s not always software → validated learning over working software → stories can drive the making of anything (doesn’t have to be software)
  • Stories describe something we can deliver and evaluate.
  • Delivery tasks describe the work we need to accomplish to realise the story
  • If the story describes a solution that’s too expensive, consider a different solution that helps you reach that goal
  • If a story is really big - break it into smaller parts that allow you to see progress sooner
  • What’s better? Half a baked cake, or a half-baked cake?

Breaking Down Stories

  • Rule of thumb: break stories down into something that takes a couple of days to build and test
  • There isn’t a single ‘right size’ for the story. It depends on what lens you have…
    • Business → something that achieves an outcome
    • Customers → something that fulfills a need
    • Development team → something that takes a couple of days to ship
  • Epics tend to be the right size for the user and the business but not the development team. An epic is a story that we expect is large, and know needs to be broken down
  • Conversations are a great tool for breaking down stories
  • You can group like stories together in themes if it’s useful
  • The End to End Story Cycle
    • Evaluate opportunities → Use opportunity discussions to agree a problem is worth solving
    • Discovery → use product discovery to find a small, viable solution
    • Prototype → build small things to help you learn
    • Story workshop → discuss the details, break down stories, agree on what to build
    • Daily Collaboration → keep talking as you build to fill in details and give feedback
    • Evaluate as a team → frequently reflect on product quality, your plans and how you work
    • Evaluate with users and customers → testing meaningful chunks of software with users
    • Evaluate with stakeholders → keep progress and quality visible
    • Evaluate after release → use metrics and face time with users to learn if your target outcomes were met
  • Break stories down progressively and just in time
    • Opportunities → who, problems, business strategy
    • Discovery → who, why, how, usable, feasible, valuable
    • Development Strategy → risks, feasibility
    • Development Cycle → what to build, acceptance criteria
  • Don’t create huge maps to discuss a single feature - map only what you need to tell a story about your feature
  • Don’t have a single story writer
    • There are too many conversations for a single person to be involved in
    • One person doesn’t brain enough expertise and diversity to arrive at the best solution
  • Valuable-Usable-Feasible → best found by a small cross-functional team led by a product owner, that orchestrates the product discovery work
  • Triad → Support product owners with a core team that includes UX, design and technical expertise
  • Three Amigos Sessions:
    • What could go wrong - edge cases → tester / developer
    • Business and user context → product
    • Look and behave → designer

Starting With Opportunities

  • Opportunity: an idea we think will solve a problem. You’re probably calling opportunities epics. Have an opportunity backlog. Hold a go/no go conversation, go means it progresses to discovery, no go means it goes in the bin or the backlog.
‣
Consider using an Opportunity Canvas (from… Marty Cagan)
  • Users and Customers
  • Problems
  • Solutions today
  • Solution Ideas
  • How will users use your solution?
  • Adoption Strategy
  • User metrics
  • Business Challenges
  • Budget
  • Business Benefits and Metrics
‣
Actual Canvas
image
  • Having a journey map might help you spot opportunities for your product
    • Types of users
    • High level product flow
    • Pain
    • Rewards
    • Opportunities

Product Discovery → Build a Shared Understanding and do Validated Learning

  • The goal of product discovery isn’t to get something built, it’s to learn if we’re building the right thing.
    • What problems are we really solving?
    • What solutions could be valuable to our organisation? and to customers?
    • What does a usable solution look like?
    • What’s feasible to build given the time and tools that we have?
  • Approach is a combination of Lean Startup, Lean UX and Design Thinking
  • Validated Learning Loop: Build → Measure → Learn
    • Build - a minimum viable product experiment
    • Measure- the impact on users, collect subjective and objective data
    • Learn - use what you’ve learnt to change your path
  • Approach Steps
    • ‣
    Frame the opportunity
    • What is the big idea? Who are the customers? Who are the users? Why would they want it? Why are we building it? (company goals)
    ‣
    Validate the problem you’re solving exists
    • Talk to customers, validate they have the problem, validate they’ll buy the solution, understand how they solve the problem now
    ‣
    Sketch and prototype

    - so you can envision your solution

    ‣
    Prototype and test
    • the smallest possible version of something to make sure you’re onto something
  • Build to learn. Iterate until viable.
  • Eric Rees should have named it MVPe (Minimum Viable Product Experiment) instead of MVP.
  • Don’t believe that your minimum viable solution will be successful. Expect 20% to work as expected, 20% to be genuine failures and everything else to fall in between
  • Design Thinking Approach…
    • Empathise→ talk to customers and users - experience their challenges first hand
    • Define/Focus→ really focus on one or a few problems - state them specifically
    • Ideate → come up with multiple solutions to customer and user problems
    • Prototype → explore your best solutions to a fidelity that allows evaluation
    • Test → test them with real customers or prospects
    • *** loop again, iterate and improve ***
  • Lean Startup + Design Thinking…
    • Guess
    • Name the risky assumptions
    • Design and build a small test
    • Measure by running your test with customers and users
    • Rethink your solution and your assumptions
  • Lean startup approach, failing to learn is frequently the biggest failure.

Ceremonies

  • Story Workshop:
    • Goal: Refine understanding and define specifically what the development team will build
    • A product conversation, supported by pictures and data
    • Get the right people, keep it to a few attendees, make it optional
    • Deep dive into:
      • Who the user is
      • How they would use it
      • What it looks like
      • How the software behaves
      • How we might build it
    • Agree on what to build
      • What will we check to confirm this is done?
      • How will we demo it?
  • Tactics: Talk and doc, speak in examples, split up big stories and thin out stories by removing unnecessary extras
  • Sprint Planning:
    • Allow team members to opt in
    • If everyone want’s to participate - try using ‘fish bowl’ collaboration
      • Small group doing the needful (limit to 5)
      • Interested people can hover on the perimeter (they can step in if somebody steps out)
      • Those of the periphery can come and go
  • Play Good, Better, Best
    • What’s good enough to get things working?
    • What would make it better?
    • What’s the best version we can imagine?
  • Development Cycle Planning
    • Choose stories a cycle or two ahead
    • Workshop ahead of time.
    • Invite the whole team
    • Plan: discuss the big goal for the upcoming cycle
    • Review the stories you’ll be discussing
    • Set a time-box for the delivery team to plan
    • In small groups, create a plan for each story
    • All together, agree on the plan.
    • Celebrate - You’re done
  • Tag stories in a mapped backlog to show progress

Learn from Everything you build

  • Have a team product review and reflection → should you raise quality or release?
  • Widen the audience to include interested stakeholders.
  • Learn from users → test the working solution with users
  • Learn from the release to users → build metrics that allow you track usage and measure outcomes. Schedule time to observe users as they use the new release
  • Software is never really done
  • Outcomes are never assured
  • Improvements made after release are the most valuable
Great art is never finished, only abandoned Da Vinci