User Story Mapping – brief summary in bullet points

User Story mapping

This is a brief summary of the book User Story mapping by Jeff Patton – in bullet points.

 ————-

  1. The real goal of using user stories is shared understanding
  2. Shared documents are not shared understanding. Shared understanding is when both understand what the other person is imagining and why.
  3. Good documents are like vacation photos – the details in having that photo taken are not available – hence you won’t get the whole picture.
  4. There is always more to build that we have time or resources to build – always
  5. Minimize output and maximize outcome and impact
  6. Stories aren’t a written form of requirements, telling stories through collaboration with words and pictures is a mechanism that builds shared understanding
  7. Stories are not the requirements, they are discussions about solving problems for our organizations, our customers, and users that lead to agreements on what to build

Chapter 1 – The Big Picture

  1. Stories get their name from how they should be used, not what should be written
  2. Story maps are for breaking down big stories as you tell them
  3. Talk and doc – write cards or sticky notes to externalize your thinking as you tell stories.
  4. Reorganizing cards together allows you to communicate without saying a word
  5. Mapping your story helps you find holes in your thinking
  6. Focus on the breadth of the story before diving into the depth

Chapter 2 – Plan to Build Less

  1. Mapping helps big groups build shared understanding
  2. Map for a product release across multiple teams to visualize dependencies
  3. Scope doesn’t creep – understanding grows
  4. Focus on what you hope will happen outside the system to make decisions about what’s inside the system
  5. Focus on outcomes – what users need to do and see when the system comes out – and slice out those releases that will get you those outcomes.
  6. Focusing on specific target outcomes is the secret to prioritizing development work
  7. A simple prioritization model has 4 aspects
    1. Differentiator – a feature that set them apart from their competition
    2. Spoiler – a feature that is moving in on someone else’s differentiator
    3. Cost reducer – a feature that reduces the organization costs
    4. Table stakes – a feature necessary to compete in the market place
  8. The Minimum Viable Product is the smallest product release that successfully achieves its desired outcomes
  9. The Minimum Viable solution is the smallest solution release that successfully achieves its desired outcomes
  10. A Minimum Viable Product is also the smallest thing you could create or do to prove or disprove an assumption

Chapter 3 – Plan to learn faster

  1. Validate that the problems you are solving actually exist
  2. Sketch and prototype so you can envision your solution
  3. Prototype and test with users to learn whether your solution is valuable and usable
  4. Treat every release as an experiment and be mindful of what you want to learn
  5. The goal is not to get something built, rather it is to learn if we are building the right thing

Chapter 4 – Plan to finish on time

  1. Map only what you need to support the conversation
  2. The best estimates come from developers who really understand what they are estimating
  3. Use iterative thinking to evaluate and make changes to what you have already made
  4. Use incremental thinking to make additions

Chapter 5 – You already know how

  1. Write out your story a step at a time
    1. User tasks are the basic building blocks of a story map
    2. Use goal level concept to help you aggregate small tasks or decompose large tasks
  2. Organize your story
    1. Maps are organized left to right using a narrative flow, the order in which you would tell the story
  3. Explore alternative stories
    1. Details, alternatives, variations and exceptions fill in the body of the map
  4. Distil your map to make a backbone
    1. Activities aggregate tasks directed at a goal
    2. Activities and high level tasks form the backbone of a story map
  5.  Slice out tasks that help you reach a specific outcome
    1. Use slices to identify all the tasks and details relevant to a specific outcome
  • Tasks are short verb phrases that describe what people do
  • Tasks have different goal levels
  • Tasks in a map are arranged in left to right narrative flow
  • The depth of a map contains variations and alternative tasks
  • Tasks are organized by activities across the top of themap
  • Activities form the backbone of the map
  • You can slice the map to identify the tasks you will need to reach a specific outcome.

Six Steps to Story Mapping

  1. Frame the problem – who is it for and why are we building it
  2. Map the big picture – focus on the breadth, not the depth.
  3. Explore – go deep and talk about other types of users and people, how else they might do things and the kind of things that can go wrong
  4. Slice out a release strategy – focus on what you are trying to achieve for your business and on the people your product will serve
  5. Slice out a learning strategy – use the map and discussions to find your bigger risks, slice your map into minimum viable product experiments
  6. Slice out a developmental strategy – focus on building things early that help you learn to spot technical issues and development risks sooner

Chapter 6 – The real story about stories

  1. The best solutions come from collaboration between the people with the problems to solve and the people who can solve them
  2. Story conversations are about working together to arrive at a best solution to a problem we both understand
  3. Good story conversations have lots of words and pictures

Chapter 7 – Telling better stories

  1. Use simple story template to start conversations
  2. It doesn’t need to be written in a template to be considered a story
  3. Checklist of what to really talk about
    1. Really talk about who
    2. Really talk about what
    3. Really talk about why
    4. Talk about what’s going on outside the software
    5. Talk about what goes wrong
    6. Talk about questions and assumptions
    7. Talk about better solutions
    8. Talk about how
    9. Talk about how long

Chapter 8 – It is not all on the card

  1. There are many different kinds of conversations with different people for every story
  2. What should be on a story card
    1. Short title
    2. Description
    3. Story number
    4. Estimate, size or budget
    5. Value
    6. Metrics
    7. Dependencies
    8. Status
    9. Dates
  3. Use a document camera or a web camera during a video conference to let remote people see what is being created on the wall
  4. Use tools to post pictures, videos and text to help you retain and remember your conversations
  5. Use tools to sequence, analyze and track progress

Chapter 9 – the card is just the beginning

  1. Handling off all the details about the story to some one else to build doesn’t work
  2. Inspect the results of your work
    1. User experience quality
    2. Functional quality
    3. Code quality
  3. Try using stories to drive the making of anything whether it is software or not

Chapter 10 – Bake stories like a cake

  1. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal
  2. If the story describes a solution that’s affordable but big, break it into smaller parts that will allow you to evaluate and see progress sooner
  3. Don’t break down big things into big plans. Break big things into small things with small plans
  4. Luke Hohman – “deliver half a baked cake, not a half baked cake”. Half a baked cake may not be enough to feed a wedding party, but it is enough to taste and leave everyone looking forward to the rest of the cake.

Chapter  11 – Rock breaking

  1. A right sized story from a user’s perspective is one that fulfils a need
  2. A right sized story from a development team’s perspective is one that just takes a few days to build and test
  3. A right size story from a business perspective is one that helps business achieve business outcome
  4. Conversations are one of the best tools for breaking down of big stories
  5. An epic is a story that we expect is large and know needs to be broken down
  6. Use opportunity discussions to agree the problem is worth solving – to make a go forward or trash decision
  7. Use discovery conversations and exploration to find a small viable solution
  8. During discovery you will dig deep into
    1. Who the customers and users are you believe will use your solution
    2. How they meet their needs today without your solution
    3. How the world would change for them with your solution
    4. How your solution might look and behave
    5. How long your solution might take to build
  9. Use deep dive story workshop s to discuss the details break down stories and really agree on specifically what you will build
  10. Frequently reflect on product quality, your plans and the way you work
  11. Learn by testing meaningful chunks of working software with customers and users
  12. Keep the progress and quality visible to stakeholders in the organization
  13. Use metrics and conversations with users to really learn if the target outcomes were met

Chapter  12 Rock breakers

  1. Requiring a single product owner to write all of the stories and be present for all story conversations does not work
  2. Valuable – Usable – Feasible – Marty Cagan describes the responsibility of the Product manager to identify a product that is valuable, usable and feasible.
  3. A small cross functional team led by product owner orchestrates product discovery work
  4. Support product owners with a core team that includes user experience, design expertise and technical expertise

Chapter 13 – Start with opportunities

  1. Have conversations about opportunities
    1. Who they are for
    2. What problems are we solving
    3. What we are imagining
    4. Why
    5. Size
  2. Product Canvas – Marty Cagan’s Opportunity assessment template
    1. Problems or solutions
    2. Users and customers
    3. Solutions today
    4. User value
    5. User metrics
    6. Adoption strategy
    7. Business problem
    8. Business metrics
    9. Budget

Chapter  14 – using Discovery to build Shared Understanding

  1. Discovery is not about building software – it is about building a deeper understanding of what we could build. It would mean asking questions like
    1. What problems are we really solving
    2. What solutions could be valuable to our organization and to customers buying or adopting the product
    3. What does a usable solution look like
    4. What’s feasible  to build given the time and the tools we have
  2. 4 essential steps to Discovery
    1. Frame the idea – to set the bounds for the work
    2. Understand customers and users – gain insight of the features and how it would benefit them, personas
    3. Envision your solution – envision how your target customers and users will make use of the solution – combine/brainstorm ideas, refine and come to a shared understanding of what the software should look like
    4. Minimize and plan – cut away more ideas that you keep, prioritize them

Chapter 15 – using discovery for validated learning

  1. Design thinking
    1. Empathize – understand how it really feels to be a user of your product, talk directly to them and experience their challenges
    2. Define (Focus) – build shared understanding – focus on one or a few problems
    3. Ideate  – come up with multiple possible solutions to customer and user problems
    4. Prototype  – build simple prototypes to help filter a lot of ideas that wont work
    5. Test – learn whether the solution could really solve someone’s problem – iterate and improve
  2. Short validated learning loops – Build Measure Learn
  3. How Lean Startup thinking changes Product design
    1. Start by guessing
    2. Identify your risky assumptions
    3. Design and build a small test
    4. Measure by running your test with customers and users
    5. Rethink your solution and assumptions

Chapter 16 – Refine, Define and Build

  1. Meeting is the word that has become a euphemism for unproductive collaboration
  2. Allow team members to participate in /opt in to the conversations. A Fishbowl collaboration (small effective group inside, interested members outside) pattern could also be used
  3. Use a map to visualize progress

Chapter 17 – Stories are actually like asteroids

  1. Break stories down progressively and just in time
  2. At each story discussion and splitting stage, you do so with a purpose in mind
    1. For opportunities, you discuss what they are for, what problems they solve.
    2. During discovery, you discuss who would use the product, why and how
    3. When planning a development strategy, you discuss what the risks are
    4. When planning for the next development cycle, you decide exactly what to build and make agreements on how you would check to confirm it is complete
  3. You could also look at bundling similar stories together to form a bigger story

Chapter 18 – Learn from everything you build

  1. Review as a team
  2. Review with others in the organization
  3. Learn from release to users – improvements made after release are most valuable
  4. Evaluate release readiness across the backbone of a map
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s