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:

☝️ 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:

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