User Story Mapping Read online

  Because so many organizations have adopted Agile and Lean processes, and stories along with them, you may fall into one or more of the traps caused by misconceptions about stories. Traps like these:

  Because stories let you focus on building small things, it’s easy to lose sight of the big picture. The result is often a “Franken-product” where it’s clear to everyone using the product that it’s assembled from mismatched parts.

  When you’re building a product of any significant size, building one small thing after another leaves people wondering when you’ll ever be done, or what exactly you’ll deliver. If you’re the builder, you wonder, too.

  Because stories are about conversations, people use that idea to avoid writing anything down. Then they forget what they talked about and agreed to in the conversations.

  Because good stories are supposed to have acceptance criteria, we focus on getting acceptance criteria written, but there’s still not a common understanding of what needs to be built. As a consequence, teams don’t finish the work they plan on in the timeframe they planned to.

  Because good stories are supposed to be written from a user’s perspective, and there are lots of parts that users never see, team members argue that "our product doesn’t have users, so user stories won’t work here."

  If you’ve fallen into any of those traps, then I’ll try to wipe away the misconceptions that lead to those traps in the first place. You’ll learn how to think of the big picture, how to plan and estimate in the large (and in the small), and how to have productive conversations about what users are trying to accomplish, as well as what a good piece of software needs to do to help them.

  Who Should Read This Book?

  You should, of course. Especially if you bought it. I, for one, think you’ve made a wise investment. If you’re just borrowing it, you should order your own now, and return the one you’ve borrowed when the new one arrives at your door.

  However, reading this book offers specific reasons and benefits for practitioners in specific roles:

  Product managers and user experience (UX) practitioners in commercial product companies should read this book to help them bridge the gap between thinking about whole products and user experience and thinking about tactical plans and backlog items. If you’ve been struggling to get from the vision you’re imagining to the details your teams can build, story maps will help. If you’ve been struggling to help others imagine the experience of — and empathize with — the users of your product, story mapping will help. If you’ve been struggling to figure out how to incorporate good UX and product design practice, this book will help. If you’ve been working to incorporate Lean Startup–style experimentation in the way you work, this book will help.

  Product owners, business analysts, and project managers in information technology (IT) organizations should read this book to help them bridge the gap between their internal users, stakeholders, and developers. If you’ve been struggling to convince lots of stakeholders in your company to get on the same page, then story maps will help. If you’ve been struggling to help developers see the big picture, story maps will help.

  Agile and Lean process coaches with the goal of helping individuals and teams improve should read this book. And, as you do, think about the misconceptions people in your organization have about stories. Use the stories, simple exercises, and practices described in this book to help your teams improve.

  Everyone else. When using Agile processes, we often look to roles like product owners or business analysts to steer a lot of the work with stories, but effective use of stories requires that everyone get the basics. When people don’t understand the basics, you hear complaints that “stories aren’t well written” or that they’re “too big,” or that they “don’t have enough detail.” This book will help, but not in the way you think. You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations. This book will help you understand what kinds of conversations you should be having to help you get the information you need when you need it.

  I’m hoping you identify with one or more of the groups I just described. If you don’t, give this book to someone who does.

  If you do, let’s get started.

  A Few Conventions Used in This Book

  I suspect this isn’t the only book on software development you’ve ever read, so nothing should surprise you.

  The Headings Inside Each Chapter Guide You Through the Subject

  Use them to find your way or skip over stuff you’re not interested in right now.

  Key points look like this. Imagine me saying these a bit louder than all the other text.

  If you’re skimming, read the key points. If you like them, or they’re not dead obvious, read the text before and after them. That should make them clear.

  Sidebars are used to describe:

  Interesting but not critical concepts. These should be fun distractions. At least I hope they are.

  Recipes for specific practices. You should be able to use these recipes to help you get started with a specific practice.

  Stories and examples contributed by others. You should get some good ideas from these that you could try in your organization.

  The book is organized into specific sections. You could read it a section at a time, or use the sections to help you find ideas for a specific challenge you have right now.

  How This Book Is Organized

  I bought a cool new color laser printer a while back. I opened the box, and sitting on top of the printer was a pamphlet with “Read This First” in big red letters on it. I wondered, “Should I really read this first?” because I usually don’t do as I’m told. But I’m glad I did, because there were lots of plastic guards in various places inside the printer to keep it safe during shipping, and if I’d plugged it in before removing them, I might have damaged the printer.

  This story might sound like a tangent, but it’s not.

  This book contains a “Read This First” chapter because there are two critical concepts and associated vocabulary that I’ll use throughout the rest of the book. I’d like you to have those concepts in your head before you get started. If you start to story map before you understand them, I can’t guarantee your safety.

  Story Mapping from 10,000 Feet

  Chapters 1–4 will give you a high-level view of story mapping. If you’ve been using stories for a while and played with a story map before, this section should give you enough to get going right away.

  Chapter 5 gives you a nifty exercise to help you learn the key concepts used to create a great story map. Try it out with a group in your office, and everyone who participates will get it. And I promise you the maps they create for your products will come out better afterward.

  Grokking User Stories

  Chapters 6–12 tell the story behind stories, how they really work, and how to make good use of them in Agile and Lean projects. Inside story maps are lots of little stories you can use to drive day-to-day development. Even if you’re an Agile veteran, I promise you’ll learn something about stories you didn’t already know. And, if you’re new to stories, you’ll learn enough to surprise the Agile know-it-alls at your office.

  Better Backlogs

  Chapters 13–15 dive deep into the lifecycle of a story. I’ll discuss specific practices that help you use stories and story maps, starting with big opportunities and moving through the discovery work to identify a backlog full of stories that describe a viable product. You’ll learn how story maps and lots of other practices can help you every step of the way.

  Better Building

  Chapters 16–18 dive deeper into using stories tactically, iteration-by-iteration or sprint-by-sprint. You’ll learn how to get stories ready, to pay attention while they’re built, to really get them done, and to really learn from each story you convert to working software.

  I find that the last few chapters of many software development books are the extra junk. I can usually ignore them. Unfortunately, I didn’t write any of those chapters. You’ll need to read the whole book. My only consolation to you is that you’ll get some useful nuggets out of every chapter that you can put to work right away.

  Let’s get to it.

  Safari® Books Online

  Note

  Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

  Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

  Safari Books Online offers a range of plans and pricing for enterprise, government, education, and individuals.

  Members have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and hundreds more. For more information about Safari Books Online, please visit us online.

  How to Contact Us

  Please address comments and questions concerning this book to the publisher:

  O’Reilly Media, Inc.

  1005 Gravenstein Highway North

  Sebastopol, CA 95472

  800-998-9938 (in the United States or Canada)

  707-829-0515 (international or local)

  707-829-0104 (fax)

  We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/user-story-mapping.

  To comment or ask technical questions about this book, send email to [email protected].

  For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

  Find us on Facebook: http://facebook.com/oreilly

  Follow us on Twitter: http://twitter.com/oreillymedia

  Watch us on YouTube: http://www.youtube.com/oreillymedia

  Read This First

  This book has no introduction.

  Yes, you read that right. Now, you might immediately ask yourself, “Why doesn’t Jeff’s book have an introduction? Did he forget to write it? Is he beginning to slip after all these years?! Did the dog eat it?”

  No, I didn’t forget to write an introduction to this book. And, no, I’m not beginning to slip. At least I don’t think I am. And my dog didn’t eat it (although my daughter’s guinea pig looks suspicious). It’s just that I’ve long believed that authors spend too much time convincing me I should read their book, and a great deal of that convincing lives in the introduction. The meat of most books usually doesn’t start until Chapter 3. And I’m sure it’s not only me who does this, but I usually skip the introduction.

  This book actually starts here.

  And you’re not allowed to skip this because it really is the most important part. In fact, if you only get two points from this book, I’ll be happy. And those two points are right here in this chapter:

  The goal of using stories isn’t to write better stories.

  The goal of product development isn’t to make products.

  Let me explain.

  The Telephone Game

  I’m sure you remember when you were a kid and you played this weird “telephone game” where you whispered something to somebody, who whispered it to someone else, and so on around the group, until the last person reveals the totally garbled message and everyone laughs. Today, my family still plays this game at home with my kids around the dinner table. Note to parents: this is a good activity to occupy kids bored with adult dinner conversation.

  In the grown-up world, we’ve continued this game — only we don’t whisper to each other. We write lengthy documents and create official-looking presentations that we hand off to someone, who proceeds to get something completely different out of it than we intended. And that person uses that document to create more documents to give to different people. However, unlike that game we played as kids, we don’t all laugh at the end.

  When people read written instructions, they interpret them differently. If you find that a little hard to believe (it’s in writing, after all!), then let me show you a few examples of instructions gone very, very wrong.

  This is the cover of Jen Yates’s book Cake Wrecks (Andrews McMeel Publishing). (Thanks to Jen and John Yates for supplying these.) The book sprang from her wildly entertaining website, cakewrecks.com. Please don’t go there if you don’t have at least an hour to waste. The site shows photos of oddly decorated cakes that defy explanation — but Jen explains them in spite of that. Now, one of the recurring themes in both the site and the book is misinterpreted requirements. But of course she doesn’t refer to them as requirements because it’s such a nerdy word. She calls them literals because the reader read and literally interpreted what was written. Looking at the photos, I can imagine someone listening to a customer and writing down what he wants, then handing that to someone else who’ll decorate a cake.

  Customer: Hello, I’d like to order a cake.

  Employee: Sure, what would you like written on it?

  Customer: Could you write “So long, Alicia” in purple?

  Employee: Sure.

  Customer: And put stars around it?

  Employee: No problem. I’ve written this up, and will hand it to my cake decorator right away. We’ll have it for you in the morning.

  This is the result:

  Here’s another. In software development, we call these nonfunctional requirements:

  These are funny examples, and we can laugh about wasting twenty bucks on a cake. But sometimes the stakes are much greater than that.

  You’ve probably heard the story about the 1999 crash of a $125 million NASA Mars Climate Orbiter.[1] OK, maybe you haven’t. But here’s the punch line. If any project is sunk up to its eyeballs in requirements and written documentation, it’s a NASA project. However, despite all the filing cabinets full of requirements and documentation, the orbiter crashed because while NASA used the metric system for its measurements, members of the Lockheed Martin engineering team used the old imperial measurement system to develop navigation commands for the vehicle’s thrusters. While no one knows exactly where the orbiter ended up, some think it has found its happy place orbiting the sun somewhere past Mars.

  Ironically, we put stuff in writing to communicate more clearly and to avoid risk of misunderstanding. But, way too often, the opposite is true.

  Shared documents aren’t shared understanding.

  Stop for a minute and write that down. Write it on a sticky note and put it in your pocket. Consider getting it tattooed somewhere on your body so you can see it when you’re getting ready for work in the morning. When you read it, it’ll help you remember the stories I’m telling you now.

  Shared understanding is when we both understand what the other person is imagining and why. Obviously, there wasn’t shared understanding between several cake decorators and the people who gave them instructions in writing. And, at NASA, someone important didn’t share understanding with others working on the guidance system. I’m sure if you’ve been involved in software development for a while, you don’t have to reach back far in your memory to recall a situation where two people believed they were in agreement on a feature they wanted to add to the software, but later found out that the way one imagined it was wildly different from the other.

  Building Shared Understanding Is Disruptively Simple

  A former coworker of mine, Luke Barrett, first drew this cartoon to describe this problem. I asked him where he first saw it, but he didn’t remember. So someone out there isn’t getting the credit he or she deserves. For years I saw Luke step through these four frames as slides in a PowerPoint deck while I casually dismissed them as interesting but obvious. Apparently I’ve got a thick head. It’s taken me many years to understand how this cartoon illustrates the most important thing about using stories in software development.

  The idea is that if I have an idea in my head and I describe it in writing, when you read that document, you might quite possibly imagine something different. We could even ask everyone, “Do you all agree with what’s written there?” and we might all say, “Yes! Yes, we do.”

  However, if we get together and talk, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes. If we give each other time to explain our thoughts with words and pictures, we build shared understanding. It’s at this point, though, that we realize that we all understood things differently. That sucks. But at least now we know.

  It’s not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas. That’s why externalizing our ideas is so important. We can redraw sketches or move sticky notes around, and the cool thing is that we’re really moving ideas around. What we’re really doing is evolving our shared understanding. That’s super-hard with just words alone.