User Story Maps: Secrets for Better Backlogs and Planning
Download as PPT, PDF41 likes8,128 views
The document discusses the importance of user story mapping in agile development, focusing on how it facilitates better communication about user experiences with products. It outlines the structure of story maps, the lifecycle of user stories, and emphasizes collaborative planning to ensure user needs are met effectively. Additionally, it highlights techniques for refining stories and prioritizing product features to drive incremental releases.
![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?)](https://image.slidesharecdn.com/agile-roots-story-mapping-140409190048-phpapp02/85/User-Story-Maps-Secrets-for-Better-Backlogs-and-Planning-21-320.jpg)
More Related Content
Similar to User Story Maps: Secrets for Better Backlogs and Planning (20)
User Story Maps: Secrets for Better Backlogs and Planning
- 1. Building Better Backlogs with User Story Mapping comakers
- 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. 4comakers, LLC :: About me
- 5. 5comakers, LLC :: [email protected] 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 1comakers, LLC :: [email protected] The Story Map
- 7. 7comakers, LLC :: [email protected] 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. 8comakers, LLC :: [email protected] 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. 9comakers, LLC :: [email protected] Key concepts Sketch a quick image/diagram for each, based on what you remember story map backbone other types of maps
- 10. 10 2comakers, LLC :: [email protected] What you need to know about user stories
- 11. 11comakers, LLC :: [email protected]://www.cakewrecks.blogspot.com Specifying in writing doesn’t work well
- 12. 12comakers, LLC :: [email protected] user Stories facilitate a conversation with a goal of shared understanding developer
- 13. 13comakers, LLC :: [email protected] Stories have a simple lifecycle ! ? Card Conversation ! Confirmation Consequences ! ?? ! Construction * Ron Jeffries coined the 3 C’s in Extreme Programming Installed
- 14. 14 BA comakers, LLC :: [email protected] user testerPM UX Designer Stories need to support lots of conversations across lots of project roles developer business leader
- 15. 15comakers, LLC :: [email protected] 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
- 17. 17comakers, LLC :: [email protected] First we need to agree on why we’re here Our job is to change the world really, I’m not kidding
- 18. 18comakers, LLC :: [email protected] How to change the world
- 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. 20comakers, LLC :: [email protected] 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. 21comakers, LLC :: [email protected] 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. That story’s too big! That story’s too big! Stories should describe software that can be built in a couple days
- 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. 24comakers, LLC :: There’s no right size for stories for all conversations
- 25. 25comakers, LLC :: [email protected] user product manager The natural “unit of measure” for stories varies by conversation BA or UI Designer developer business leader
- 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. release cycle development cycle User Stories shrink in size and grow in detail as they travel through a pipeline
- 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. 29comakers, LLC :: [email protected] 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. 30comakers, LLC :: [email protected] 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 3comakers, LLC :: [email protected] Starting a map
- 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. 33comakers, LLC :: [email protected] 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. 34comakers, LLC :: [email protected] Build the backbone of your map by: 1. Discussing experience and then mapping
- 35. 35comakers, LLC :: [email protected] Building a backlog as a story map is a discussion about user experience, not user stories
- 36. 36comakers, LLC :: [email protected] 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)
- 38. 38comakers, LLC :: [email protected] 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. 39comakers, LLC :: [email protected] 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. 40comakers, LLC :: [email protected] A narrative imagines the experience of a product that doesn’t yet exist UI Storyboard from Margarete Fuss, SAP AG
- 41. 41comakers, LLC :: [email protected] Story map under a story board Photo courtesy of Carbonite, Boston, MA 41
- 42. 42comakers, LLC :: [email protected] Think: “mile wide inch deep” or “breadth not depth” You’re trying to get the big picture
- 43. 43comakers, LLC :: [email protected] 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 4comakers, LLC :: [email protected] Filling in and Validating
- 45. 45comakers, LLC :: [email protected] Discuss, fill in, refine the map, and test for completeness
- 46. 46comakers, LLC :: [email protected] 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 add, rewrite,split,combine,reorganize add, rewrite,split,combine,reorganize comakers, LLC :: [email protected] 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. 48comakers, LLC :: [email protected] 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 5comakers, LLC :: [email protected] Planning incremental product releases
- 50. 50comakers, LLC :: [email protected] Prioritize stories vertically then “slice” to small valuable releases
- 51. 51comakers, LLC :: [email protected] Adding tape lines to the wall lets participants organize stories into layers 51
- 52. 52comakers, LLC :: [email protected] Maps have latitude and longitude 52 sequence (time from the user’s perspective) priority (time from the planner and builder’s perspective)
- 53. 53comakers, LLC :: [email protected] Planning incremental releases can be a whole team event 53
- 54. 54comakers, LLC :: [email protected] Releases target business outcomes, customer, and user segments * Menlo Innovations organizes personas into a target to help focus releases
- 55. 55comakers, LLC :: [email protected] Use target personas to drive release strategy Target a primary persona for a first release Try a “good-better-best” strategy
- 56. 56comakers, LLC :: [email protected] 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. 57comakers, LLC :: [email protected] You’ll spend most of your time filling in and validating
- 58. 58comakers, LLC :: [email protected] 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 6comakers, LLC :: [email protected] Mapping experience (you already know this stuff)
- 60. 60comakers, LLC :: Learn by mapping an experience you know
- 61. 61comakers, LLC :: [email protected] 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. 62comakers, LLC :: [email protected] Play along and quickly list all the things you did to get ready this morning...
- 63. 63comakers, LLC :: We naturally think in tasks
- 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. 65comakers, LLC :: [email protected] 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. 66comakers, LLC :: [email protected] The exercise looks like this 66
- 67. 67comakers, LLC :: [email protected] People naturally build a two-dimensional map 67 sub-tasks, alternatives, variations, and details An imperfect narrative flow
- 68. 68comakers, LLC :: [email protected] 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. 69comakers, LLC :: We naturally group tasks into activities
- 70. 70comakers, LLC :: [email protected] 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. 71comakers, LLC :: [email protected] Experience maps describe the world today 71 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
- 72. 72comakers, LLC :: [email protected] Experience maps describe the world today 72 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
- 73. 73comakers, LLC :: [email protected] The biggest benefit of modeling this way is not the data in the model
- 74. 74comakers, LLC :: [email protected] Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
- 75. 75comakers, LLC :: [email protected] Representing our ideas as models allows us to detect inconsistencies in our understanding
- 76. 76comakers, LLC :: [email protected] Through discussion and iterative model building we arrive at a stronger shared understanding
- 77. 77comakers, LLC :: [email protected] Using that shared understanding we can work together to arrive at the same objectives
- 78. 78comakers, LLC :: [email protected] Shared understanding is critical to successful collaborative work
- 79. 79comakers, LLC :: [email protected] Model collaboratively to build shared understanding
- 80. 80comakers, LLC :: [email protected] 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. 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?
- 83. Building Better Backlogs with User Story Mapping Thank you!Thank you! comakers
Editor's Notes
- #4: 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.
- #5: 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.
- #11: In the late 1990s Kent Beck coined the term “Story.” In Extreme Programming Explained stories describe an alternative to working with traditional requirements
- #18: The real purpose of what we do in software development is to change the world
- #20: <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.
- #25: Myth: stories have a “right size” for all conversations
- #63: Before advancing, look at your list... what part of speech does each item in your list start with? I predict verbs.
- #72: 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.
- #73: 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.
- #82: 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.