Mike Cohn (1) (1962–)

Agile methods are just different than traditional approaches, kind of like Einsteinian physics is just different from Newtonian physics. They both have the same aims; they only have wildly different ways of getting there. Instead of estimating software schedules by reality-based values, agile creates abstractions like user stories, story points, and velocities to measure progress. Burndown charts project how quickly a feature set can be released. Maybe I'm an old fogey in the world of show more computer programming, but I still prefer reality-based metrics to predict our progress. Nevertheless, I'm not enough of an old fogey to be unwilling to learn new techniques that pervade all the software tools I use to manage my projects. In this book, Mike Cohn gives me an in-depth look at how these methods and tools function together.

The weirdest thing remains to me how abstract and detached from reality these tools are. They seem helpful in predicting teamwork on large projects, but I still question whether they are a panacea that requires their use everywhere. I can certainly see many situations where they can help estimations, but in a world which bills by the hour, such as my coders do, these abstractions don't help as much. They can predict a launch date quickly without much effort, but they don't provide a framework to break down the work so that a programmer can predict the amount of time that'll be spent on a project. By enlightening me on the whole system, Cohn has given me more of a light to see how agile project-management methods can indeed bring about results better.

Agile techniques are here to stay in the software domain, and this book will continue to enlighten advanced practitioners and project managers how to measure progress going forward. They certainly reduce the amount of torque businesses can place on their developers and replace them with more creative fun that produces better results. Though twenty years old, Cohn's book conveys these techniques in a way still relevant to today's world. It's worth reading to those involved in getting things done by creating software. show less

Arranged like a textbook with questions answered in an appendix, this includes a historical arc of Agile from the innovations of Extreme Programming (XP). The User Story focus is weighted toward the physical collateral (index cards, etc.) and face-to-face collaboration on development, including thought-provoking, imaginative peronae writing. This is a very good, gentle introduction to the technique.

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 show more 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. show less

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 show more 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. show less