Agile Estimating and Planning

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

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

Continuing the author's series of must-read books, "Agile Estimating and Planning" clearly, quickly, yet thoroughly takes you through the topic, imparting techniques and judgement on optional variants, along with aposite insights into how these techniques contribute to making Agile processes more effective than rivals.

And if that's not enough for you, I think the book might be worth the price just for the quotes that head off each chapter:

Planning is everything. Plans are nothing.

A good plan violently executed now is better than a perfect plan executed next week.

In a good shoe, I wear a size six. But a seven feels so good, I buy a size eight.

To achieve great things, two things are needed: a plan, and not quite enough time.