Successfully reported this slideshow.
Your SlideShare is downloading. ×

User Story Maps: Secrets for Better Backlogs and Planning

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 83 Ad

User Story Maps: Secrets for Better Backlogs and Planning

Download to read offline

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.

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.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to User Story Maps: Secrets for Better Backlogs and Planning (20)

Recently uploaded (20)

Advertisement

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

Editor's Notes

  • Before we leap, I’d like you to write a now and later card, or sticky, or notebook page.
    What’s your situation right now as you’re listening to this?
    What’s causing you pain?
    Glance at this and think of this as you listen today. Make some notes about anything you hear that could make things better.
    Later, at the end of this seminar, I’ll ask you to look back and consider what you’ve heard and imagine a “later” that’s better. You’ll make some notes about what you could do to leverage some of the stuff you’ve heard to make a better later. Because if you can’t leverage it, you’ve wasted your time.... and we’d both hate that.
  • I’m Jeff Patton
    I’m a college art school dropout who went into software development, because for me, programming was easier. Certainly easier than all that hard work it took to be really good at illustration and graphic design.
    If you’re a software developer with a bit of an art background, some of you may know that this makes you the UI guy.
    My earliest bad memories of software development come from being there when someone first used software I’d poured a lot of hard work into. I remember standing behind someone struggling to figure out my product. I'd been so confident before. I was sure they were going to love it as much as I did.
    If any of you can remember being there the first time a product you designed was used, you know what I mean
    It was after that experience that I learned that the only way for me to succeed was to not assume I knew my users well,
    or assume I was smarter than they were.
    I'd have to honestly spend the time to understand them
    I'd have to get something in frront of them sooner if I wanted to learn faster. I found I always learned something when I spent time with people that were goiing to use more product.
    And after succeeding a few times, I became adicted to creating things that really helped people.
    It was after a few years of this when learned what being a UI guy really meant.
    In 2000 I first heard of a process called Extreme Programming. They promised to spend lots of face time with customers and users and get small amounts of software in front of people sooner. I thought I’d found a group that valued the same things I did.
    But bubble quickly burst for me. I realized that in practice XP meant:
    * get a smart person who already knows what to build and call them ‘the customer,’
    * ask them exactly what to build,
    * build it for them,
    * and when they hate it explain to them that that’s the way it’s supposed to work. It’s ‘agile.’
    Now don't get me wrong. I really do like agile processes. I like agile ideals. But since my first exprience in 2000 I've been on a rampage... I've been committed add the same level of rigor in decidng what to build that agile processes put into to building. When I add good UX practice and good product thinking to agile - it's exactly the way I want to work.
    What you're going to get is a dose of the kinds of thinking and practice I've been championing for the last decade.
  • In the late 1990s Kent Beck coined the term “Story.” In Extreme Programming Explained stories describe an alternative to working with traditional requirements
  • The real purpose of what we do in software development is to change the world
  • <stories aren’t about the solution, they’re about the world with the solution in it>
    who, what, and why – they describe the future world.
    They’re super hard to write if you can’t imagine the future world.
    Many years ago I spoke with a game designer who said “to succeed, you have to be able to play the game in your head.” I thought he was crazy - but I get it now.
  • Myth: stories have a “right size” for all conversations
  • Before advancing, look at your list... what part of speech does each item in your list start with? I predict verbs.
  • In Pruitt and Adlin’s book “The Persona Lifecycle” they describe the creating journey maps. They’re a good example of what I’m talking about.
  • Journey maps integrate tasks, comments, pain points, questions, and solution ideas.
    Duncan Brown from the Caplin group sent me a few photos of their journey maps. They integrate photos from contextual studies and a nifty emotional barometer on the top.
    This simple 2D map is a handy structure for visualizing experience, seeing big patterns, and moving from big ideas into little ideas.
  • Before we leap, I’d like you to write a now and later card, or sticky, or notebook page.
    What’s your situation right now as you’re listening to this?
    What’s causing you pain?
    Glance at this and think of this as you listen today. Make some notes about anything you hear that could make things better.
    Later, at the end of this seminar, I’ll ask you to look back and consider what you’ve heard and imagine a “later” that’s better. You’ll make some notes about what you could do to leverage some of the stuff you’ve heard to make a better later. Because if you can’t leverage it, you’ve wasted your time.... and we’d both hate that.

×