I’ve just finished a wonderful book, “Agile Estimating And Planning” by Mike Cohn. At first, I wasn’t sure what this book could teach me because I saw estimating as just an informed way of guessing. Cohn has done a remarkable job of laying out the foundations on estimating effort and time.

Traditional planning has failed for a variety of reasons. Work is broken down into tasks and a Gantt chart is drawn up. When there is a delay in one task, it will cause a delay on all the tasks that depend on it. Since the work is broken down by tasks, there is no sense of their importance, so figuring out what to drop when the deadline approaches becomes difficult. The individuals responsible for implementing the feature is asked to create an estimate, which causes a problem if that person is not available the whole duration for that task. It is difficult to come up with good estimates because more effort you put into estimating doesn’t necessarily make your estimates better.

The book proposes that we should work cooperatively. We start by estimating the size of the story (a description of a feature) in comparison to other features (figuring that something is twice as big as something else is a lot easier than trying to figure out how long it would take to implement them). You make estimates based on the story itself, not by how one individual would get it done because you never know if that person would be called off to do something else. You work is organized by features not by tasks so everyone works together to make sure that feature works. When you organize it by tasks it puts the burden on the person responsible for it.

Another important theme of the book is to work on the most important stories first. The importance is determined by the customer. Each story has a value to ther customer and each iteration should add immediate value to the project.

After you have a good set of stories, the group take on as much work as they can handle for an iteration (set as two or four weeks, the group decides). At the end of the iteration, you can see how well you did on your estimates, so the next time you can adjust the number of points for the next iteration. Once you have an idea of the number of points you can do for an iteration (the velocity), you can estimate estimate how long it would take to do a release. The formula is (total story points)/(velocity) = number of iterations . The author takes the idea further by introducing buffers. There are feature buffers and schedule buffers. For feature buffers, you add in all the mandatory features and buffer it with optional features that you’ll work on if time permits. For schedule buffers, you add a buffer to the schedule so you don’t miss a deadline. This is done by taking the number of points a story would be if there is a 50% chance of completion and if there is a 90% chance. You find the difference and square them. You total up these values for the rest of the stories in your iteration and find the square root. That would be the number of points you need for a buffer.

The book also has ideas on solving some issues that may come up, such as splitting stories, how to come to a consensus on the number of points for a story, how long should your iterations be, what actually determines a story, categorizing features (must-haves, exciters, linear) what to do when you are partially finished (you don’t get points until it’s completely finished), and how to keep track of the progress.

All the ideas come together at the end of the book in a fictional case study. The author does an excellent job running through a simple story of a group faced with a new project and trying out the agile methodologies. Stories are created and sized, questions are asked and answered, an iteration is completed, a release is estimated and progress report is given. I really enjoyed the book. It’s definitely something you should have in your collection.