Agile Estimating and Planning by Mike Cohn

Planning and estimating is by far the most difficult part of any technology project, and this book takes many of the lessons of other Agile approaches and applies them specifically to planning and estimating in an eminently practical way.

Introduction

The author is an engineer and this book is clearly written for other engineers. The writing style is unapologetically terse, forthright and wonderfully pedantic, from the use of the international currency symbol (¤) used throughout when referring to money to a religious alternation of personal pronouns. The book is larded with common sense, and although some parts are overly systematic in my view (such as the financial planning parts), there are many very practical suggestions that obviously come from direct personal experience.

The author also clearly knows whereof he speaks – Chapter 2 Why Planning Fails is an excellent account of the many problems with IT planning such as Activities Don’t Finish Early (Parkinson’s Law), Lateness Is Passed Down the Schedule (only one thing needs to be late to make a project late) and Activities are not Independent (if one thing takes longer than you expected, then probably all of them will).

The one that in my previous career has always plagued me is Estimates Become Commitments. Anyone who has been trapped by that last bugbear will know the greatest problem with implementing Agile approaches anywhere – how to keep all stakeholders on board. This book contains a lot of useful practical information to help avoid assumed commitments and how to keep your customer happy even when there is a lot of uncertainty.

The author puts the problem succinctly An agile project is more like a timed race than a 10-kilometer race: run as far as possible in sixty minutes… the agile project team knows when they will finish but not what they will deliver. This book is very strong is providing an overall structure for development activities that includes planning and estimating exercises as a core part of initiation and of each iteration, and in a way that should help maintain stakeholder confidence.

Estimating Size

This is the core of all useful software planning techniques, and one where things often fall down immediately. The author starts with a method of assigning Story Points to user stories. These are just relative weights – a 2 indicating that a use case is twice as hard/complex/long as something with 1 point. He then introduces a system for determining a team’s velocity by adding up the story points they complete in an iteration, and using that for forward planning.

This is a nice idea, and neatly deals with the problem of Activities are not Independent (i.e. if one feature is harder than expected, then probably all of them are).

The author also discusses Ideal Days, which are perhaps a more natural way of estimating size for most people. Although he presents the idea in detail the author clearly strongly prefers story points, and he is persuasive. The concept of velocity is a strong one, and we’ll be using this approach ourselves.

Planning for Value

This section of the book discusses a wide range of different concepts, all of which can be useful depending on the sort of projects being worked on.
A large part of this section discusses methods for estimating the financial value of a software project, to allow a go/no go decision to be made. This section is very theoretical, with a discussion of, for example Net Present Value versus Internal Rate of Return. I have my doubts as to how useful these things are in practice – the results are eminently massagable and much of the important part of a go/no-go decision is an intuitive belief in the proposal. What these methods do provide, I suppose, is a mechanism for justification that’s very difficult to argue against. This may be useful for an individual, but regular use of these sorts of exercises are often a sign of a disfunctional organisation. Handle with care.

There is some good stuff in this section too though – using Kano’s Model of Customer Satisfaction explicitly as a way of prioritising user stories is a great idea, and the way of structuring this into a survey is the best systematic way of involving a user community in planning that I’ve seen.

There is also some good guidance on splitting user stories here. The user stories the author uses are very terse, and so harder to split. He provides some good guidance on how to make them small enough to fit into an iteration.

Scheduling

This section presents an overall way of structuring activity into a Release Plan, prioritising stories, assigning them to iterations and then breaking stories into tasks. There is also some good guidance on how tasks should be structured, and he covers some of the key agile issues such as automated unit testing and bugfixing within iterations.

He also makes the key point that dependencies don’t matter – this is something I have found myself, and is quite counter-intuitive: because of automated user testing you need to build test versions of many modules anyway, to provide controlled data, so the unavailability of the real thing is irrelevant – your stub code is in itself valuable. It is sometimes even useful to build in this way, because it forces you to consider module APIs independently of implementation (one of the major advantages to the unit testing practice as a whole in fact).

The section on “Uncertainty” has some excellent points for how to cope with applying these techniques in the real world. The biggest problem we have as agile developers is working in an environment where some sort of up-front commitments are required. Using the techniques presented in this chapter, it is possible to provide early commitments, but to frame them with appropriate errors and buffer them appropriately, so that we can make commitments we can really meet.

Tracking and Communicating

This section starts with a number of ways of monitoring and communicating progress, such as the traditional Burndown Chart. We use Trac, which has some good reporting, so I’m going to stick with that. A later post will deal with Agile development using Trac.

The author also covers how to communicate plans, and does suggest a number of useful techniques for expressing them (including, amazingly, Gantt charts).

The final sections of the book summarise everything that has gone before, and presents a very useful fictional account of development using the techniques he discusses.

Conclusion

This is a very useful book for anyone applying Agile practices, and I think could provide a lot of the missing ‘glue’ for teams that are trying to be more agile but have trouble interfacing that with real customers. Using appropriate planning techniques can gain customer confidence earlier in the process, and so allow you to defer more of the architecture and design work to happen during iterations.