User Story Mapping (Jeff Patton) (Z-Library)

SOF T WARE DESIGN User Story Mapping ISBN: 978-1-491-90490-9 US $34.99 CAN $36.99 “ I have met only a few Agile experts whom I consider qualified to actually help a serious product team raise its game to the level its company needs and deserves. Jeff Patton is one of them.” —Marty Cagan Partner, Silicon Valley Product Group Twitter: @oreillymedia facebook.com/oreilly User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. Author Jeff Patton shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. ■ Get a high-level view of story mapping, with an exercise to learn key concepts quickly ■ Understand how stories really work, and how they come to life in Agile and Lean projects ■ Dive into a story’s lifecycle, starting with opportunities and moving deeper into discovery ■ Prepare your stories, pay attention while they’re built, and learn from those you convert to working software Jeff Patton is an independent consultant, agile process coach, product design process coach, and instructor with more than 15 years of experience designing and building software products. He’s been focused on agile approaches since working on an early extreme programming team in 2000. U ser Story M apping Patton Jeff Patton with Peter Economy Forewords by Martin Fowler, Alan Cooper, and Marty Cagan User Story Mapping DISCOVER THE WHOLE STORY, BUILD THE RIGHT PRODUCT www.it-ebooks.info

SOF T WARE DESIGN User Story Mapping ISBN: 978-1-491-90490-9 US $34.99 CAN $36.99 “ I have met only a few Agile experts whom I consider qualified to actually help a serious product team raise its game to the level its company needs and deserves. Jeff Patton is one of them.” —Marty Cagan Partner, Silicon Valley Product Group Twitter: @oreillymedia facebook.com/oreilly User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. Author Jeff Patton shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. ■ Get a high-level view of story mapping, with an exercise to learn key concepts quickly ■ Understand how stories really work, and how they come to life in Agile and Lean projects ■ Dive into a story’s lifecycle, starting with opportunities and moving deeper into discovery ■ Prepare your stories, pay attention while they’re built, and learn from those you convert to working software Jeff Patton is an independent consultant, agile process coach, product design process coach, and instructor with more than 15 years of experience designing and building software products. He’s been focused on agile approaches since working on an early extreme programming team in 2000. U ser Story M apping Patton Jeff Patton with Peter Economy Forewords by Martin Fowler, Alan Cooper, and Marty Cagan User Story Mapping DISCOVER THE WHOLE STORY, BUILD THE RIGHT PRODUCT www.it-ebooks.info

Jeff Patton User Story Mapping www.it-ebooks.info

User Story Mapping by Jeff Patton Copyright © 2014 Jeff Patton. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Editors: Mary Treseler and Amy Jollymore Production Editor: Kara Ebrahim Copyeditor: Rachel Monaghan Proofreader: Elise Morrison Indexer: Ellen Troutman Cover Designer: Ellie Volckhausen Interior Designer: David Futato Illustrator: Rebecca Demarest September 2014: First Edition Revision History for the First Edition: 2014-09-05: First release See http://oreilly.com/catalog/errata.csp?isbn=9781491904909 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. User Story Mapping, the image of a lilac-breasted roller, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their prod‐ ucts are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 978-1-491-90490-9 [LSI] www.it-ebooks.info

For Stacy, Grace, and Zoe who are my biggest supporters and make all my effort worthwhile. And in memory of Luke Barrett, a dear colleague and mentor of mine. Luke made a difference in my life as he did countless others. www.it-ebooks.info

www.it-ebooks.info

Table of Contents Foreword by Martin Fowler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Foreword by Alan Cooper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Foreword by Marty Cagan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Read This First. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix 1. The Big Picture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 The "A" Word 1 Telling Stories, Not Writing Stories 3 Telling the Whole Story 3 Gary and the Tragedy of the Flat Backlog 5 Talk and Doc 6 Frame Your Idea 8 Describe Your Customers and Users 9 Tell Your Users' Stories 10 Explore Details and Options 14 2. Plan to Build Less. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Mapping Helps Big Groups Build Shared Understanding 22 Mapping Helps You Spot Holes in Your Story 25 There’s Always Too Much 26 Slice Out a Minimum Viable Product Release 27 Slice Out a Release Roadmap 28 Don’t Prioritize Features—Prioritize Outcomes 29 This Is Magic—Really, It Is 30 Why We Argue So Much About MVP 32 The New MVP Isn’t a Product at All! 34 v www.it-ebooks.info

3. Plan to Learn Faster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Start by Discussing Your Opportunity 38 Validate the Problem 39 Prototype to Learn 40 Watch Out for What People Say They Want 41 Build to Learn 41 Iterate Until Viable 44 How to Do It the Wrong Way 44 Validated Learning 46 Really Minimize Your Experiments 48 Let’s Recap 48 4. Plan to Finish on Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Tell It to the Team 52 The Secret to Good Estimation 53 Plan to Build Piece by Piece 54 Don’t Release Each Slice 56 The Other Secret to Good Estimation 56 Manage Your Budget 57 What Would da Vinci Do? 59 Iterative AND Incremental 62 Opening-, Mid-, and Endgame Strategy 63 Slice Out Your Development Strategy in a Map 64 It’s All About Risk 64 Now What? 65 5. You Already Know How. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 1. Write Out Your Story a Step at a Time 67 Tasks Are What We Do 68 My Tasks Are Different Than Yours 69 I’m Just More Detail-Oriented 70 2. Organize Your Story 71 Fill in Missing Details 72 3. Explore Alternative Stories 72 Keep the Flow 74 4. Distill Your Map to Make a Backbone 75 5. Slice Out Tasks That Help You Reach a Specific Outcome 76 That’s It! You’ve Learned All the Important Concepts 77 Do Try This at Home, or at Work 78 It’s a Now Map, Not a Later Map 79 Try This for Real 81 vi | Table of Contents www.it-ebooks.info

With Software It’s Harder 82 The Map Is Just the Beginning 84 6. The Real Story About Stories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Kent’s Disruptively Simple Idea 89 Simple Isn’t Easy 91 Ron Jeffries and the 3 Cs 92 1. Card 93 2. Conversation 93 3. Confirmation 94 Words and Pictures 95 That’s It 96 7. Telling Better Stories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Connextra’s Cool Template 97 Template Zombies and the Snowplow 102 A Checklist of What to Really Talk About 104 Create Vacation Photos 107 It’s a Lot to Worry About 108 8. It’s Not All on the Card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Different People, Different Conversations 109 We’re Gonna Need a Bigger Card 110 Radiators and Ice Boxes 113 That’s Not What That Tool Is For 116 Building Shared Understanding 116 Remembering 118 Tracking 119 9. The Card Is Just the Beginning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Construct with a Clear Picture in Your Head 122 Build an Oral Tradition of Storytelling 123 Inspect the Results of Your Work 124 It’s Not for You 126 Build to Learn 127 It’s Not Always Software 128 Plan to Learn, and Learn to Plan 129 10. Bake Stories Like Cake. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Create a Recipe 132 Breaking Down a Big Cake 133 Table of Contents | vii www.it-ebooks.info

11. Rock Breaking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Size Always Matters 137 Stories Are Like Rocks 139 Epics Are Big Rocks Sometimes Used to Hit People 140 Themes Organize Groups of Stories 142 Forget Those Terms and Focus on Storytelling 142 Start with Opportunities 143 Discover a Minimum Viable Solution 144 Dive into the Details of Each Story During Delivery 146 Keep Talking as You Build 148 Evaluate Each Piece 149 Evaluate with Users and Customers 150 Evaluate with Business Stakeholders 152 Release and Keep Evaluating 153 12. Rock Breakers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Valuable-Usable-Feasible 156 A Discovery Team Needs Lots of Others to Succeed 158 The Three Amigos 159 Product Owner as Producer 163 This Is Complicated 164 13. Start with Opportunities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Have Conversations About Opportunities 167 Dig Deeper, Trash It, or Think About It 168 Opportunity Shouldn’t Be a Euphemism 173 Story Mapping and Opportunities 173 Be Picky 179 14. Using Discovery to Build Shared Understanding. . . . . . . . . . . . . . . . 181 Discovery Isn’t About Building Software 181 Four Essential Steps to Discovery 182 1. Frame the Idea 183 2. Understand Customers and Users 183 3. Envision Your Solution 186 4. Minimize and Plan 196 Discovery Activities, Discussions, and Artifacts 199 Discovery Is for Building Shared Understanding 200 15. Using Discovery for Validated Learning. . . . . . . . . . . . . . . . . . . . . . . 201 We’re Wrong Most of the Time 201 viii | Table of Contents www.it-ebooks.info

The Bad Old Days 203 Empathize, Focus, Ideate, Prototype, Test 204 How to Mess Up a Good Thing 208 Short Validated Learning Loops 209 How Lean Startup Thinking Changes Product Design 210 Start by Guessing 211 Name Your Risky Assumptions 212 Design and Build a Small Test 212 Measure by Running Your Test with Customers and Users 214 Rethink Your Solution and Your Assumptions 215 Stories and Story Maps? 215 16. Refine, Define, and Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Cards, Conversation, More Cards, More Conversations… 217 Cutting and Polishing 218 Workshopping Stories 218 Sprint or Iteration Planning? 222 Crowds Don’t Collaborate 225 Split and Thin 227 Use Your Story Map During Delivery 232 Use a Map to Visualize Progress 233 Use Simple Maps During Story Workshops 234 17. Stories Are Actually Like Asteroids. . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Reassembling Broken Rocks 241 Don’t Overdo the Mapping 243 Don’t Sweat the Small Stuff 244 18. Learn from Everything You Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Review as a Team 247 Review with Others in Your Organization 251 Enough 253 Learn from Users 254 Learn from Release to Users 255 Outcomes on a Schedule 255 Use a Map to Evaluate Release Readiness 256 The End, or Is It?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Table of Contents | ix www.it-ebooks.info

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 x | Table of Contents www.it-ebooks.info

Foreword by Martin Fowler One of the beneficial consequences of the rise of Agile software de‐ velopment is the notion of splitting up large sets of requirements into smaller chunks. These chunks—stories—enable much more visibility into the progress of a development project. When a product is built story-by-story, with each story’s implementation fully integrated into the software product, everyone can see the product grow. By using stories that make sense to users, developers can steer the project by determining which stories to build next. This greater visibility helps encourage greater participation from users—no longer do they have to wait a year or more to see what the development team’s been up to. But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by get‐ ting lost in the details. Story mapping is a technique that provides the big picture that a pile of stories so often misses. That’s it, really—the description of this book in a single sentence. And that sentence carries with it the promise of a lot of value. A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. When I talk to my colleagues at Thought‐ Works about what they do to develop their stories, story mapping regularly comes up as a core technique. Often they’ve learned that technique from workshops run by Jeff, because he’s the one who developed the technique and can best communicate it. This book xi www.it-ebooks.info

allows more people to understand this technique directly from its source. But this isn’t just a book for people who have something like "business analyst" on their business card or online profile. Perhaps the biggest disappointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way commu‐ nication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users' needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software— leading to a better job. When Kent Beck (who originated the notion of a "story") developed his ideas on software development, he called out communication as a key value of effective teams. Stories are the building blocks of com‐ munication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of soft‐ ware development itself. —Martin Fowler June 18, 2014 xii | Foreword by Martin Fowler www.it-ebooks.info

Foreword by Alan Cooper In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts. Yet this is what software developers attempt to do all the time. They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that develop‐ ers are using their construction method as a design tool, but the two are not interchangeable. It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at- a-time yields a Frankenstein monster of a program. While they are intimately related, the practice of designing software behavior and the practice of building that software are distinctly dif‐ ferent, and are typically performed by different people with different skill sets. The many hours that interaction designers spend observing users and mapping behavior patterns would drive most programmers batty. Conversely, the hours of sweating over algorithms are too soli‐ tary for most designers. But when the two strains of practice—design and development—col‐ laborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it. xiii www.it-ebooks.info

While the idea of collaboration is neither new nor particularly in‐ sightful, it is actually very difficult to do effectively. The way that de‐ velopers work—their pace, language, and rhythm—is quite different from that of interaction designers. Practitioners in each of the two fields are strong, capable, and inter‐ nally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction be‐ tween the two disciplines is precisely where Jeff Patton lives. Jeff ’s method of story mapping makes sense to developers, and it makes equal sense to designers. Story mapping is the Rosetta Stone for our digital age. Despite protestations to the contrary, Agile development is not a very useful design tool. It is a way of thinking about development that is design-friendly, which is a very good thing, but by itself it won’t get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation. Patton’s story mapping approach is the bridge over this chasm. Inter‐ action design is all about finding the user’s truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. It’s so ridiculously easy for the essence of the narrative to slip away during this complex process. Yes, the functions are implemented, but the patient dies on the operating room table. By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of the user’s story, remains intact throughout the development. The conventional corporate world has proven that it is nearly impos‐ sible for a team of two or three hundred people to build a product that people love. Meanwhile the startup community has proven that a team of four or five people can build small products that people love, but even these little products eventually grow big and lose their spark. The challenge we face is creating big software that people love. Big software xiv | Foreword by Alan Cooper www.it-ebooks.info

serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn. The only way we are going to build big software that is not a Frank‐ enstein monster is by learning how to integrate the disciplines of soft‐ ware design and development. Nobody knows how to do that better than Jeff Patton. —Alan Cooper June 17, 2014 Foreword by Alan Cooper | xv www.it-ebooks.info

www.it-ebooks.info

Foreword by Marty Cagan I’ve had the extremely good fortune to be able to work with many of the very best technology product teams in the world. People creating the products you use and love every day. Teams that are literally changing the world. I’ve also been brought in to try to help companies that are not doing so well. Startups racing to get some traction before the money runs out. Larger companies struggling to replicate their early innovation. Teams failing to continuously add value to their business. Leaders frustrated with how long it takes to go from idea to reality. Engineers exasperated with their product owners. What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. I mean everything from how leaders behave to the level of empowerment of teams; to the way teams work together; to how the organization thinks about funding, staffing, and producing products; to the culture; to how product, design, and engineering collaborate to discover effective solutions for their customers. This book is titled User Story Mapping, but you’ll soon see it is about much more than this powerful yet simple technique. This book gets to the heart about how teams collaborate, communicate, and ulti‐ mately come up with good stuff to build. Many of you have never had a chance to see up close how a strong product team operates. All you may know is what you’ve seen at your company or where you’ve worked before. So what I’d like to do here xvii www.it-ebooks.info

is to try to give you a flavor of just how different the best teams are from the rest. With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differ‐ ences between strong product teams and weak teams: Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their score‐ card KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from con‐ stantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers. Good teams understand who their key stakeholders are, they under‐ stand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders. Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps. Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something. Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their re‐ spective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings. Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test. Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are. Good teams ensure that their engineers have time to try out the dis‐ covery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate. Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s re‐ sponse to their latest ideas. Bad teams think they are the customer. xviii | Foreword by Marty Cagan www.it-ebooks.info