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.

Table of Contents

1. The Big Picture

2. Plan to Build Less

3. Plan to Learn Faster

4. Plan to Finish on Time

5. You Already Know How

6. The Real Story About Stories.

7. Telling Better Stories

8. It’s Not All on the Card

9. The Card Is Just the Beginning

10. Bake Stories Like Cake

11. Rock Breaking

12. Rock Breakers

13. Start with Opportunities

14. Using Discovery to Build Shared Understanding

15. Using Discovery for Validated Learning

16. Refine, Define, and Build

17. Stories Are Actually Like Asteroids

18. Learn from Everything You Build

The End, or Is It?

About the Authors

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.

Martin Fowler is an author, speaker, consultant and general loud-mouth on software development.

He concentrates on designing enterprise software - looking at what makes a good design and what practices are needed to come up with good design. He has pioneered object-oriented technology, refactoring, patterns, agile methodologies, domain modeling, the Unified Modeling Language (UML), and Extreme Programming.

He's the Chief Scientist at ThoughtWorks - an international application development company, and has written five books on software development: Analysis Patterns, UML Distilled (now in its 3rd edition), Refactoring, Planning Extreme Programming (with Kent Beck), and Patterns of Enterprise Application Architecture.