Preface
Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.
— Tom Waits, “Step Right Up”
This book was supposed to be a small thing…a pamphlet, really.
I set out to write about a simple practice I called story mapping. I, and lots of other folks, build simple maps to help us work together with others and to imagine the experience of using a product.
Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.
Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.
How complicated could writing a book about this be?
But it turns out that even the simple things can be pretty sophisticated. And writing about why you would want to build a story map, what’s going on when you build one, and all the different ways you can use one took me a lot of pages. There was more to this simple practice than I thought.
If you’re using an Agile development process, you’re likely filling backlogs with user stories. I’d assumed that since stories were such a common practice, it’d be a waste of time for me to write about them in this book. But I was wrong. In the decade and a half since stories were first described by Kent Beck, they’re more popular—and more misunderstood and misused—than ever before. That makes me sad. And, what’s more, it kills all the benefit we get from story mapping.
So, in this book, I would like to correct as many big misconceptions as I can about stories and the way they’re used in Agile and Lean software development. That’s why, in the words of Tom Waits, I’ve turned this “sandwich into a banquet.”
Why Me?
I like making things. What motivates me is the joy I get from creating a piece of software and seeing people use it and benefit from it. I’m a reluctant methodologist. I found I needed to learn how process and practice work to get better at them. I’m only now learning after 20-plus years in software development how to teach what I’ve learned. And I know that what I teach is a moving target. What I understand changes every week. How best to explain it changes almost as fast. All that’s kept me from writing a book for years.
But it’s time.
Stories and story maps are such a good idea. They’ve benefited so many people. They’ve made their lives better, and the products they build better. But while some people’s lives are getting better, there are more people struggling with stories than ever before. I want to help stop that.
This book is something I can make to help. And, if it improves the work lives of even a few, I’ll celebrate.
This Book Is for You If You’re Struggling with Stories
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.
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