Agile Estimating and Planning

A few months ago my company picked up a new project with a fairly major government organization. The mission is to migrate several applications from a mainframe (Natural / Adabas) to a modern environment (C# / SQL Server). We were told that the mainframe was going to be disabled in about 9 months . . . period.

I told the client very early in the process that a typical waterfall approach would be impossible to implement under the conditions of the project and that we should take an agile methodology. The client agreed; however, the lack of resources corralled a few of our team members back to the waterfall approach. After a few weeks in waterfall, we realized that there was no way a waterfall project could be successful in this case.

We officially switched back to an agile approach and the project has been swimming along nicely ever since. I owe a lot of this success to Agile Estimating and Planning by Mike Cohn.

Agile Estimating and Planning is part of the Robert C. Martin Series and is listed in every "Top 10 Agile Books" lists I've found. The book is full of well thought out logical explanations and detailed examples of agile software development practices and principles. It is a very easy read (I read it in 2 days) and the author did an excellent job of relating each chapter to other chapters in the book.

The book begins by pointing out the difference between planning an agile project and agile planning. Next, Mike describes several reasons planning fails in many projects (some of which I discuss in my blog post a few weeks ago called "Programming is a Gas").

The next several chapters discuss the benefits and techniques of abstracting estimations away from time and monetary units. This creates a set of relative estimations based on feature complexity that allows the project room to change over time (and promotes more open and honest communication with the client). Two techniques discussed specifically are story points and ideal days.

The following section is more planning oriented with a detailed discussion of themes, features, and prioritization. There is a discussion about what to do with epics (very large stories) and boundaries on which to split those stories. Conversely, there is also a discussion about combining several small but related user stories into one larger more meaningful one.

The scheduling section describes release and iteration planning, estimating velocity, and techniques for buffering projects (especially risky projects). the tracking and communicating section gives you a set of methods for monitoring the release and iteration plans and a tool set you can use to communicate this with the project stakeholders.

The next section describes how (and why) agile projects work so well in real life. High visibility into the project, frequent feature based planning, and small story size make agile projects preferred for many software development groups as well as many clients who have had the good fortune to have experienced a well run agile project.

The final chapter is a hypothetical case study which demonstrates the entire agile software development life cycle from beginning to end. In this chapter, you get to see how an agile project begins, how stakeholders become involved, how iterations are planned, and how easily problems can be solved. If you read carefully, you can also pick up a lot of insight Mike has to offer from his experience as an agile coach.

You can purchase Agile Estimating and Planning from Amazon.com at a deeply discounted rate.