User Story Maps: Secrets for Better Backlogs and Planning
Upcoming SlideShare
Loading in...5
×
 

User Story Maps: Secrets for Better Backlogs and Planning

on

  • 563 views

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: ...

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.

Statistics

Views

Total Views
563
Views on SlideShare
558
Embed Views
5

Actions

Likes
8
Downloads
20
Comments
0

2 Embeds 5

https://twitter.com 4
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Before we leap, I’d like you to write a now and later card, or sticky, or notebook page. <br /> What’s your situation right now as you’re listening to this? <br /> What’s causing you pain? <br /> Glance at this and think of this as you listen today. Make some notes about anything you hear that could make things better. <br /> 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. <br />
  • I’m Jeff Patton <br /> 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. <br /> 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. <br /> 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&apos;d been so confident before. I was sure they were going to love it as much as I did. <br /> If any of you can remember being there the first time a product you designed was used, you know what I mean <br /> 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, <br /> or assume I was smarter than they were. <br /> I&apos;d have to honestly spend the time to understand them <br /> I&apos;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. <br /> And after succeeding a few times, I became adicted to creating things that really helped people. <br /> It was after a few years of this when learned what being a UI guy really meant. <br /> 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. <br /> But bubble quickly burst for me. I realized that in practice XP meant: <br /> * get a smart person who already knows what to build and call them ‘the customer,’ <br /> * ask them exactly what to build, <br /> * build it for them, <br /> * and when they hate it explain to them that that’s the way it’s supposed to work. It’s ‘agile.’ <br /> Now don&apos;t get me wrong. I really do like agile processes. I like agile ideals. But since my first exprience in 2000 I&apos;ve been on a rampage... I&apos;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&apos;s exactly the way I want to work. <br /> What you&apos;re going to get is a dose of the kinds of thinking and practice I&apos;ve been championing for the last decade. <br />
  • In the late 1990s Kent Beck coined the term “Story.” In Extreme Programming Explained stories describe an alternative to working with traditional requirements <br />
  • The real purpose of what we do in software development is to change the world <br />
  • &lt;stories aren’t about the solution, they’re about the world with the solution in it&gt; <br /> who, what, and why – they describe the future world. <br /> They’re super hard to write if you can’t imagine the future world. <br /> 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. <br />
  • Myth: stories have a “right size” for all conversations <br />
  • Before advancing, look at your list... what part of speech does each item in your list start with? I predict verbs. <br />
  • 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. <br />
  • Journey maps integrate tasks, comments, pain points, questions, and solution ideas. <br /> 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. <br /> This simple 2D map is a handy structure for visualizing experience, seeing big patterns, and moving from big ideas into little ideas. <br />
  • Before we leap, I’d like you to write a now and later card, or sticky, or notebook page. <br /> What’s your situation right now as you’re listening to this? <br /> What’s causing you pain? <br /> Glance at this and think of this as you listen today. Make some notes about anything you hear that could make things better. <br /> 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. <br />

 User Story Maps: Secrets for Better Backlogs and Planning User Story Maps: Secrets for Better Backlogs and Planning Presentation Transcript

  • Building Better Backlogs with User Story Mapping comakers
  • 2comakers, LLC :: hello@comakewith.us
  • 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?
  • 4comakers, LLC :: About me
  • 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 1comakers, LLC :: hello@comakewith.us The Story Map
  • 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)
  • 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
  • 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 2comakers, LLC :: hello@comakewith.us What you need to know about user stories
  • 11comakers, LLC :: hello@comakewith.ushttp://www.cakewrecks.blogspot.com Specifying in writing doesn’t work well
  • 12comakers, LLC :: hello@comakewith.us user Stories facilitate a conversation with a goal of shared understanding developer
  • 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 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
  • 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
  • 16comakers, LLC :: hello@comakewith.us
  • 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
  • 18comakers, LLC :: hello@comakewith.us How to change the world
  • 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
  • 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?
  • 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?)
  • That story’s too big! That story’s too big! Stories should describe software that can be built in a couple days
  • 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
  • 24comakers, LLC :: There’s no right size for stories for all conversations
  • 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
  • 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
  • release cycle development cycle User Stories shrink in size and grow in detail as they travel through a pipeline
  • 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
  • 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
  • 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 3comakers, LLC :: hello@comakewith.us Starting a map
  • 32comakers, LLC :: Before mapping identify relevant context Business Strategy Customer Segments Users & user goals Product usages Regulatory constraints Legacy product and architecture ?What else?
  • 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
  • 34comakers, LLC :: hello@comakewith.us Build the backbone of your map by: 1. Discussing experience and then mapping
  • 35comakers, LLC :: hello@comakewith.us Building a backlog as a story map is a discussion about user experience, not user stories
  • 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)
  • 37comakers, LLC :: hello@comakewith.us 37
  • 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)
  • 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.
  • 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
  • 41comakers, LLC :: hello@comakewith.us Story map under a story board Photo courtesy of Carbonite, Boston, MA 41
  • 42comakers, LLC :: hello@comakewith.us Think: “mile wide inch deep” or “breadth not depth” You’re trying to get the big picture
  • 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 4comakers, LLC :: hello@comakewith.us Filling in and Validating
  • 45comakers, LLC :: hello@comakewith.us Discuss, fill in, refine the map, and test for completeness
  • 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 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
  • 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 5comakers, LLC :: hello@comakewith.us Planning incremental product releases
  • 50comakers, LLC :: hello@comakewith.us Prioritize stories vertically then “slice” to small valuable releases
  • 51comakers, LLC :: hello@comakewith.us Adding tape lines to the wall lets participants organize stories into layers 51
  • 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)
  • 53comakers, LLC :: hello@comakewith.us Planning incremental releases can be a whole team event 53
  • 54comakers, LLC :: hello@comakewith.us Releases target business outcomes, customer, and user segments * Menlo Innovations organizes personas into a target to help focus releases
  • 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
  • 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
  • 57comakers, LLC :: hello@comakewith.us You’ll spend most of your time filling in and validating
  • 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 6comakers, LLC :: hello@comakewith.us Mapping experience (you already know this stuff)
  • 60comakers, LLC :: Learn by mapping an experience you know
  • 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
  • 62comakers, LLC :: hello@comakewith.us Play along and quickly list all the things you did to get ready this morning...
  • 63comakers, LLC :: We naturally think in tasks
  • 64comakers, LLC :: There’s a natural “human size” for tasks * Cockburn’s Writing Effective Use Cases describes goal levels for use cases this way
  • 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
  • 66comakers, LLC :: hello@comakewith.us The exercise looks like this 66
  • 67comakers, LLC :: hello@comakewith.us People naturally build a two-dimensional map 67 sub-tasks, alternatives, variations, and details An imperfect narrative flow
  • 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
  • 69comakers, LLC :: We naturally group tasks into activities
  • 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
  • 71comakers, LLC :: hello@comakewith.us Experience maps describe the world today 71 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  • 72comakers, LLC :: hello@comakewith.us Experience maps describe the world today 72 * Narrative Journey Map courtesy Duncan Brown of the Caplin Group
  • 73comakers, LLC :: hello@comakewith.us The biggest benefit of modeling this way is not the data in the model
  • 74comakers, LLC :: hello@comakewith.us Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
  • 75comakers, LLC :: hello@comakewith.us Representing our ideas as models allows us to detect inconsistencies in our understanding
  • 76comakers, LLC :: hello@comakewith.us Through discussion and iterative model building we arrive at a stronger shared understanding
  • 77comakers, LLC :: hello@comakewith.us Using that shared understanding we can work together to arrive at the same objectives
  • 78comakers, LLC :: hello@comakewith.us Shared understanding is critical to successful collaborative work
  • 79comakers, LLC :: hello@comakewith.us Model collaboratively to build shared understanding
  • 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
  • 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?
  • 82comakers, LLC ::
  • Building Better Backlogs with User Story Mapping Thank you!Thank you! comakers