User Story Maps: Secrets for Better Backlogs and Planning

5,690 views

Published on

User story mapping is an intuitive way to build and organize a product backlog. During this session you’ll get hands-on experience building a user story map. You’ll learn:

How story mapping drives productive conversations with users and stakeholders.
How to plan incremental releases of your product using minimal holistic slices that deliver value at each product release.
Secrets to effective prioritization for both planning releases, and figuring out what to build next.
Tactical management of your backlog as you grow your working software to releasability.
The backlog building and managing strategies in this session will take you well beyond the agile basics.

Published in: Software
  • Be the first to comment

User Story Maps: Secrets for Better Backlogs and Planning

  1. 1. Building Better Backlogs with User Story Mapping comakers
  2. 2. 2comakers, LLC :: hello@comakewith.us
  3. 3. 3comakers, LLC :: 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?
  4. 4. 4comakers, LLC :: About me
  5. 5. 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
  6. 6. 6 1comakers, LLC :: hello@comakewith.us The Story Map
  7. 7. 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 details•smaller steps•alternative steps•UI details•technical details workflow(from the user’s perspective) workflow(from the user’s perspective) backbone(gives structure to themap) backbone(gives structure to themap) product goals (why build the product) product goals (why build the product) users (what are their goals) users (what are their goals)
  8. 8. 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
  9. 9. 9comakers, LLC :: hello@comakewith.us Key concepts Sketch a quick image/diagram for each, based on what you remember story map backbone other types of maps
  10. 10. 10 2comakers, LLC :: hello@comakewith.us What you need to know about user stories
  11. 11. 11comakers, LLC :: hello@comakewith.ushttp://www.cakewrecks.blogspot.com Specifying in writing doesn’t work well
  12. 12. 12comakers, LLC :: hello@comakewith.us user Stories facilitate a conversation with a goal of shared understanding developer
  13. 13. 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. 14. 14 BA comakers, LLC :: hello@comakewith.us user testerPM UX Designer Stories need to support lots of conversations across lots of project roles developer business leader
  15. 15. 15comakers, LLC :: hello@comakewith.us User Stories are boundary objects Here’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
  16. 16. 16comakers, LLC :: hello@comakewith.us
  17. 17. 17comakers, 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
  18. 18. 18comakers, LLC :: hello@comakewith.us How to change the world
  19. 19. 19© 2011 Jeff Patton, all rights reserved, www.AgileProductDesign.com Agile stories are about the future world we imagine As a I want so that
  20. 20. 20comakers, LLC :: hello@comakewith.us Imagine the future Who 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?
  21. 21. 21comakers, LLC :: hello@comakewith.us Stories gain detail over time and from conversation - don’t add all your details at once Start with a short title Add 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?)
  22. 22. That story’s too big! That story’s too big! Stories should describe software that can be built in a couple days
  23. 23. I’m not really getting what this product is about! 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
  24. 24. 24comakers, LLC :: There’s no right size for stories for all conversations
  25. 25. 25comakers, LLC :: hello@comakewith.us user product manager The natural “unit of measure” for stories varies by conversation BA or UI Designer developer business leader
  26. 26. release cycle development cycle User Stories shrink in size and grow in detail as they travel through a pipeline Capabilities 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
  27. 27. release cycle development cycle User Stories shrink in size and grow in detail as they travel through a pipeline
  28. 28. 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
  29. 29. 29comakers, LLC :: hello@comakewith.us Key concepts Ask 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
  30. 30. 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 Backlog Contains 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
  31. 31. 31 3comakers, LLC :: hello@comakewith.us Starting a map
  32. 32. 32comakers, LLC :: Before mapping identify relevant context Business Strategy Customer Segments Users & user goals Product usages Regulatory constraints Legacy product and architecture ?What else?
  33. 33. 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= Identify measurable product goals http://agileproductdesign.com/writing/patton
  34. 34. 34comakers, LLC :: hello@comakewith.us Build the backbone of your map by: 1. Discussing experience and then mapping
  35. 35. 35comakers, LLC :: hello@comakewith.us Building a backlog as a story map is a discussion about user experience, not user stories
  36. 36. 36comakers, 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)
  37. 37. 37comakers, LLC :: hello@comakewith.us 37
  38. 38. 38comakers, 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)
  39. 39. 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. Steven Credit Card Marketing Field Manager Steven 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.
  40. 40. 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
  41. 41. 41comakers, LLC :: hello@comakewith.us Story map under a story board Photo courtesy of Carbonite, Boston, MA 41
  42. 42. 42comakers, LLC :: hello@comakewith.us Think: “mile wide inch deep” or “breadth not depth” You’re trying to get the big picture
  43. 43. 43comakers, LLC :: hello@comakewith.us Key concepts Think 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
  44. 44. 44 4comakers, LLC :: hello@comakewith.us Filling in and Validating
  45. 45. 45comakers, LLC :: hello@comakewith.us Discuss, fill in, refine the map, and test for completeness
  46. 46. 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. 47. 47 add, rewrite,split,combine,reorganize 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
  48. 48. 48comakers, LLC :: hello@comakewith.us Key concepts Stand 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. 49. 49 5comakers, LLC :: hello@comakewith.us Planning incremental product releases
  50. 50. 50comakers, LLC :: hello@comakewith.us Prioritize stories vertically then “slice” to small valuable releases
  51. 51. 51comakers, LLC :: hello@comakewith.us Adding tape lines to the wall lets participants organize stories into layers 51
  52. 52. 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)
  53. 53. 53comakers, LLC :: hello@comakewith.us Planning incremental releases can be a whole team event 53
  54. 54. 54comakers, LLC :: hello@comakewith.us Releases target business outcomes, customer, and user segments * Menlo Innovations organizes personas into a target to help focus releases
  55. 55. 55comakers, LLC :: hello@comakewith.us Use target personas to drive release strategy Target a primary persona for a first release Try a “good-better-best” strategy
  56. 56. 56comakers, LLC :: hello@comakewith.us Minimal Viable Releases target success for a product with a specific target audience MVP: Minimal Viable Product MMF: Minimal Marketable Feature To thin a release, first reduce the size of your target market MVP 1 or more MMFs
  57. 57. 57comakers, LLC :: hello@comakewith.us You’ll spend most of your time filling in and validating
  58. 58. 58comakers, LLC :: hello@comakewith.us Key concepts Pop-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. 59. 59 6comakers, LLC :: hello@comakewith.us Mapping experience (you already know this stuff)
  60. 60. 60comakers, LLC :: Learn by mapping an experience you know
  61. 61. 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
  62. 62. 62comakers, LLC :: hello@comakewith.us Play along and quickly list all the things you did to get ready this morning...
  63. 63. 63comakers, LLC :: We naturally think in tasks
  64. 64. 64comakers, LLC :: There’s a natural “human size” for tasks * Cockburn’s Writing Effective Use Cases describes goal levels for use cases this way
  65. 65. 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
  66. 66. 66comakers, LLC :: hello@comakewith.us The exercise looks like this 66
  67. 67. 67comakers, LLC :: hello@comakewith.us People naturally build a two-dimensional map 67 sub-tasks, alternatives, variations, and details An imperfect narrative flow
  68. 68. 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
  69. 69. 69comakers, LLC :: We naturally group tasks into activities
  70. 70. 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
  71. 71. 71comakers, LLC :: hello@comakewith.us Experience maps describe the world today 71 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  72. 72. 72comakers, LLC :: hello@comakewith.us Experience maps describe the world today 72 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  73. 73. 73comakers, LLC :: hello@comakewith.us The biggest benefit of modeling this way is not the data in the model
  74. 74. 74comakers, LLC :: hello@comakewith.us Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
  75. 75. 75comakers, LLC :: hello@comakewith.us Representing our ideas as models allows us to detect inconsistencies in our understanding
  76. 76. 76comakers, LLC :: hello@comakewith.us Through discussion and iterative model building we arrive at a stronger shared understanding
  77. 77. 77comakers, LLC :: hello@comakewith.us Using that shared understanding we can work together to arrive at the same objectives
  78. 78. 78comakers, LLC :: hello@comakewith.us Shared understanding is critical to successful collaborative work
  79. 79. 79comakers, LLC :: hello@comakewith.us Model collaboratively to build shared understanding
  80. 80. 80comakers, LLC :: hello@comakewith.us Key concepts Write 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
  81. 81. 81comakers, LLC :: 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?
  82. 82. 82comakers, LLC ::
  83. 83. Building Better Backlogs with User Story Mapping Thank you!Thank you! comakers

×