- Paperback: 200 pages
- Publisher: OREILLY; 1 edition (31 August 2014)
- Language: English
- ISBN-10: 1491904909
- ISBN-13: 978-1491904909
- Product Dimensions: 15.2 x 1.7 x 22.9 cm
- Boxed-product Weight: 485 g
- Average Customer Review: 2 customer reviews
- Amazon Bestsellers Rank: 19,544 in Books (See Top 100 in Books)
Other Sellers on Amazon
+ FREE Delivery
+ FREE Delivery
User Story Mapping: Building Better Products Using Agile Software Design Paperback – 31 Aug 2014
|New from||Used from|
Frequently bought together
Customers who bought this item also bought
About the Author
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."
Customers who viewed this item also viewed
Showing 1-2 of 2 reviews
There was a problem filtering reviews right now. Please try again later.
Most helpful customer reviews on Amazon.com
Here, the book provides a lot of "why" (which I can tolerate) and a lot of "how" (which I would welcome eventually, but very little "what". For an impatient bugger like me, that's frustrating.
This book is aimed more at Product Managers, but I think its extremely relevant for anyone in the software development process. I'm in QA and thought it was rather insightful.
As a seasoned developer and agile practitioner, this book has been a very welcome addition to my library, and one that I will gladly recommend to friends, colleagues and interested parties.
This is not a technical guide for how to write user stories that replace requirements, rather it's a holistic approach to reaching common understanding and documenting the results of those conversations in a way that gets a quality product developed. I would recommend this book for business and IT.