User Story Mapping: Discover the Whole Story, Build the Right Product Paperback – Sep 25 2014
|New from||Used from|
Frequently Bought Together
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
Getting the download link through email is temporarily not available. Please check back later.
To get the free app, enter your mobile phone number.
About the Author
Over his past two decades of experience, Jeff Patton has learned there’s no “one right way” to design and build software, but there’s lots of wrong ways.
Jeff makes use of over 15 years experience with a wide variety of products from on-line aircraft parts ordering to electronic medical records to help organizations improve the way they work. Where many development processes focus on delivery speed and efficiency, Jeff balances those concerns with the need for building products that deliver exceptional value and marketplace success.
Jeff has focused on Agile approaches since working on an early Extreme Programming team in 2000. In particular he specializes in integrating effective user experience design and product management practice with strong engineering practice.Jeff currently works as an independent consultant, agile process coach, product design process coach, and instructor. Current articles, essays, and presentations on variety of topics in Agile product development can be found at www.AgileProductDesign.com and in Alistair Cockburn’s Crystal Clear. Jeff is founder and list moderator of the agile-usability Yahoo discussion group, a columnist with StickyMinds.com and IEEE Software, a Certified Scrum Trainer, and winner of the Agile Alliance’s 2007 Gordon Pask Award for contributions to Agile Development.
From the Publisher
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 xxiv | Preface 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.
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: (below). 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.
- 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."
What Other Items Do Customers Buy After Viewing This Item?
Top Customer Reviews
Most Helpful Customer Reviews on Amazon.com (beta)
Years ago, I said that the book "Writing Effective Use Cases" from Alistair Cockburn is the best book on "how to find out what I have to program?". As a software developer, it's often not easy to tell since rarely a customer can communicate exactly what the "system" (whatever that may be) has to be capable of.
A few years later, I said "User Stories Applied" from Mike Cohn is the best book.
At the moment, I say "User Story Mapping" from Jeff Patton is the best book on that topic.
It contains a lot of small pearls of wisdom like "Stories aren't a written form of requirements; telling stories through collaboration with words and pictures is a mechanism building shared understanding".
It's just so easy to write "User Stories" as a piece of text (just as you've been used to write "use cases" or even earlier "functional specifications").
You think you're on the safe side if you write the user stories in form of the "Connextra Template" ("As a [type of user] I want to [do something] So that I can [get some benefit]").
But it needs the advice from Jeff Patton's book to get shaken up that - at its core - it's about the many discussions that help to develop a shared understanding (customer / user <=> software develper).
And to get shaken up that you can spare most of the text that you'd be writing by using the Connextra Template if you use a Story Map (the column implies the persona, the row implies the goal).
If you read the book, you'll feel as if Jeff were sitting next to you, explaining everything in detail and with a lot of patience to you. It's all brilliantly well verbalized so that you just can't misunderstand.
I do remember a lot of metaphors from the book - which I hope to bring to my daily practice, e.g. "Vacation Photos", "Template Zombies", "Three Amigos", "Need Sizing", "Orgzonas", "Best Last Conversations", "Asteroids".
I also hope that I don't forget those quotes:
"Shared documents aren't shared understanding"
"The truth is, your job is to change the world. ... Every great idea you turn into a product solution changes the world in some small, or not-so-small way for the people who use it. In fact if it doesn't, you've failed."
"I personally believe that scope doesn't creep, understanding grows."
"You can deliver half a baked cake, not a half-baked cake."
"If you catch yourself saying 'there's not much risk or uncertainty in this project,' you need to remember that those are famous last words."
"Failing to learn is frequently the biggest failure."
All in all, the book is a great summary and explanation of how to work with user stories (and it's not just about the "how" but also about the "why").
And it's realy inspiring!
For instance, one of the common challenges I have faced in the past is deciding on how to get thin vertical slices of releasable features that add value. We used user stories in the past - but looking back at the process we always battled to see the whole picture and often didn't reach our intended goal.
I believe the process of story mapping fills this gap - this is the most effective approach I have seen to getting really good thin vertical slices of real value in a usable and pragmatic way.
Not only did I gain a deeper insight into story mapping, I also gained a deeper insight into user stories. Understanding how to move between items on a story map to user stories and back was invaluable. Jeff’s account of the history of a user stories and how they encompass multiple levels of size brought user stories back in to perspective.
My favorite section in the book was Jeff’s analogy of user stories being like the asteroids game. I immediately saw some anti-patterns we’ve done in the past. I’m not going to ruin it for you, but be sure to read that chapter.
I would recommend User Story Mapping to everyone involved in the agile process. Thank you for making the time to put these thoughts on paper - it has been invaluable.
Sections that really stood out to me included the section on Rock Breaking, Rock Breakers and Stories are actually like Asteroids
While user stories are a great tool for talking about user needs, by themselves they aren't very good at helping the team understand the big picture. If you've ever had that feeling that you're missing the forest for the trees, user story mapping can mean the difference between building the right thing, or building the wrong thing.
Although he didn't invent user story mapping, Jeff has clearly mastered it and his years of experience are finally available in this book for all to benefit from.
Using many actual examples, anecdotes, metaphors, and humor, Jeff spends the first four chapters explaining what user story maps are, what they're not, and how to apply the knowledge you gain by using them effectively. You'll also learn secrets to estimating (which shouldn't be secrets to anyone), development and delivery strategies that help you reduce risk, and how to know if you're focusing on the right outcomes and building the right thing.
This is the chapter in which Jeff explains how to build a map. And the good news is (spoiler alert), building a story map isn't hard. Using a simple example of a day in your own life, he walks you through each step and drives home each key concept.
Now that you've got a story map, the next six full chapters are devoted to understanding how user stories really work and how to get the most out of them. No matter how much you think you know about stories, you're going to learn some things you didn't know.
If the book ended at this point, I think you'd feel very satisfied that you learned more about stories and story mapping than you thought possible. But there's more.
Jeff then shares more stories and advice about the user story life cycle, managing your backlog, and lots of things you can do to discover what your product should be.
For the finale, you get three chapters devoted to `Better Building'. You'll learn how to conduct user story workshops, how to plan sprints and releases, how to collaborate (and how to not collaborate), and how to get the most from your story maps during the entire delivery process.
User story mapping is an essential tool for the tool box of anybody involved in shaping or building a product and this is the definitive book on how to do it well. The skills you'll learn will have a profound impact on your ability to learn, understand, and build great products.
User Story Mapping looks like the spinal cord to his ideas, but there's much more to it, that's why the title may be misleading. A kind of judgement mistake Jeff tries to prevent right on the first few pages of his book.
It's totally worth a read, being that kind of book that you can start experimenting the knowledge while you read it. Those with lesser experience with agile/lean methodologies may be too literal following some of the advices, while more experienced folks may find some parts of the book dispensable. For the latter, remember that it's always useful to revisit the basics in order to deal with cognitive biases that may be lurking in.
Agile Software Requirements, Specification by Example, Requirements by Collaboration are good books but honestly I think this is the best book about software (requirements) I've read so far and I recommend it to everyone from the executive to the junior developer.
Look for similar items by category
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Tools
- Books > Textbooks > Computer Science & Information Systems > Programming Languages
- Books > Textbooks > Computer Science & Information Systems > Software Design & Engineering