Agile Estimating and Planning

By Mike Cohn (2005)

Ron Jeffries:

Right now, this appears to be a 200-point project. Based on our performance on other projects (or a random guess), with N programmers on it, and your intimate involvement in the project, a project of this size will take between four and six months. However, we will be shipping software to you every two weeks, and we’ll be ticking off these feature stories to your satisfaction. The good news is that if you’re not satisfied, you can stop. The better news is that if you become satisfied before all the features are done, you can stop. The bad news is that you need to work with us to make it clear just what your satisfaction means. The best news is that whenever there are enough features working to make the program useful, you can ask us to prepare it for deployment, and we’ll do that. As we go forward, we’ll all see how fast we’re progressing, and our estimate of the time needed will improve. In every case, you’ll see what is going on, you’ll see concrete evidence of useful software running the tests that you specify, and you’ll know everything as soon as I know it.

My Notes

Planning and constant replanning is all about balancing all these interacting forces:

• What do we want?
• When can we get it?
• How are we going to do it?

☝️ All of these have a certain level of uncertainty, and they also change throughout the project.

Uncertainty is reduced by doing the work.

A plan as a set of baseline expectations (what, how, when) and can be used for making decisions.

Planning is spread out over the whole project.

There normally is not much that can be done to accelerate the completion of a task, but there are an indefinite number of things that can go wrong and delay the completion of a task.

In some organisations it looks better to over promise and not deliver 😩

Estimate relative size and derive duration (don’t estimate duration).

Kano model of customer satisfaction:

• Must have features (with just these satisfaction will never go beyond mid-point)
• Linear: the more of a feature, the better (e.g., pixels, horsepower)
• Exciters: surprised but users want them when they see them (these and linear can bring satisfaction past mid-point)

It’s important to know top priorities and least priorities (so you know quickly what can be dropped).

Guidelines

• Involve the whole team
• Express uncertainty (functionality or date depending on which is fixed)
• Acknowledge the importance of learning (communicate how the product is specified as work progresses, how previous plans are updated, how the team learns about customers, technology, don’t share timelines until velocity is established, etc)
• Leave some slack (don’t assume 100% resource utilisation)
• Coordinate teams through lookahead planning