Picture of author.

For other authors named Mike Cohn, see the disambiguation page.

7 Works 1,279 Members 13 Reviews

About the Author

Mike Coh, founder of Mountain Goat Software, provides training and consulting on Scrum and agile software development to help companies build extremely high-performance development organizations. He authored two of the agile movement's most respected books, User Stories Applied for Agile Software show more Development and Agile Estimating and Planning. Cohn has been a technology executive in companies ranging from start-ups to the Fortune 40 and has served clients including the BBC, Capital One, Electronic Arts, Experian, Google, Intuit, Lexis Nexis, Lockheed Martin, Microsoft, Nokia, Philips, Sabre, Salesforce.com, Siemens, Sony, Time Warner, Yahoo!, and many more. He cofounded the Agile Alliance, Agile Project Leadership network, and Scrum Alliance. show less

Works by Mike Cohn


Common Knowledge

Canonical name
Cohn, Mike



Like many books on agile, much of this book's ideas and tips are only useful if you are using an agile process with sprints, small tasks, team sprint planning and other features of popular agile methodologies. If your team only uses some elements of agile or is using a lighter weight agile approach such as kanban, it is less useful.

Part 1: The Problem and the Goal

A good overview of the purpose of planning. I took away two points: the process of planning is more important than the plan itself, and a plan needs to be a living document if it is to remain useful throughout the project. As a consequence of these two principles, plans should not be laid out in detail from the beginning. Instead, plans should be as detailed as needed any any given time. For example, in a traditional agile flow, the next sprint will be broken down into tasks small enough to work on while future sprints may only have a rough sequencing of features planned.

Part 2: Estimating Size

Overall, I would recommend [b:Software Estimation|93891|Software Estimation Demystifying the Black Art|Steve McConnell|http://photo.goodreads.com/books/1328830202s/93891.jpg|90512] by [a:Steve McConnell|3307|Steve McConnell|http://www.goodreads.com/assets/nophoto/nophoto-M-50x66-f6689175dd57c0b1f6246d198a230cae.jpg] over this book. This section Cohn's book goes into a bit more depth on story points, ideal days, and planning poker than McConnell's book, but overall the content in Cohn's book is a subset of that in McConnell's book.

This book did give some interesting insights into re-estimating. Re-estimating has two purposes: to provide better estimates based on current data and to learn for future estimating. Inaccurate estimates and re-estimation should not be treated as failures. Individual estimates are rarely accurate, it's the aggregation that becomes more reliable. Another reason not to treat re-estimation as failure is that it discourages honest estimation in the future. Given these two purposes of re-estimation, it's rarely worth tracking how well individual estimates matched actual work done.

Part 3: Planning for Value

This part of the book covers figuring out what to do. The chapters on prioritization were useful. Since I am not in an environment where I have to directly worry about financial prioritization, I found most useful the discussion of estimating based on desirability.

In addition to the common knowledge that priority should depend on the "ratio" of desirability to effort, the book discusses how to assess desirability. ("Ratio" is in quotes since desirability is even harder to quantify than effort.) My key takeaway was that to decide how important something is, we should ask two questions: "how happy would you be with this feature?" and "how unhappy would you be without this feature?"

It might seem like these two questions would yield inverse answers, but consider a feature like saving in a text editor: if you just asked people how happy it would make them, it would likely get a middling score, but people would be very unhappy if their editor couldn't save. These are the features that are taken for granted, the things which would be deal breakers if you didn't add them. By only asking the first question, these features might be missed.

Part 4: Scheduling

Not particularly useful if you don't use an iteration based agile process.

Part 5: Tracking and Communicating

Also not so useful if you don't use an iteration based agile process.

Part 6: Why Agile Planning Works

A good summary of the book. Many of the highlights of the book can be gleaned from this one chapter section.

Part 7: A Case Study

Brought everything together nicely. It doesn't show how to deal with things going wrong, but since the purpose was to demonstrate the ideas to reinforce them, that is reasonable.
… (more)
eri_kars | 4 other reviews | Jul 10, 2022 |
A must read if you are an agile coach. Lot's of practical information that you can use to support organizations in improving agile practices.
BenLinders | 2 other reviews | Jul 30, 2017 |
This short book promises to explain what User Stories are, what they aren't, how to create and utilize them within an Agile/XP approach, and finally how to bring everything together in a short, yet relatively realistic case study. It delivers exactly what it promises and the exercises at the end of the chapters, although not always very well crafted, help the reader to capture the essence of each chapter, as well as focus on the pitfalls. It is not repetitive and does not try to be everything for every type of software developer, and that I consider another positive point.

No matter what methodology you use, software development is a challenging task, and even if your favorite method is Agile or a variation of it, you'll need hard earned experience and probably more than just one book, but if I had to recommend only one introductory book to someone who wants to get the essence of creating User Stories to capture most of the aspects of end user software, then this book would be it.
… (more)
EmreSevinc | 4 other reviews | Aug 17, 2013 |
Good book about new processes we can use to create software for end users.
Dangraham | 4 other reviews | Jan 4, 2011 |


You May Also Like

Associated Authors

Kent Beck Foreword



Charts & Graphs