The Art of Agile Development

Estimating

Note

Programmers

We provide reliable estimates.

Programmers often consider estimating to be a black art—one of the most difficult things they must do. Many programmers find that they consistently estimate too low. To counter this problem, they pad their estimates (multiplying by three is a common approach), but sometimes even these rough guesses are too low.

Are good estimates possible? Of course! You just need to focus on your strengths.

What Works (and Doesn’t) in Estimating

One reason estimating is so difficult is that programmers can rarely predict how they will spend their time. A task that requires eight hours of uninterrupted concentration can take two or three days if the programmer must deal with constant interruptions. It can take even longer if the programmer works on another task at the same time.

Important

Estimate in ideal time.

Part of the secret to making good estimates is to predict the effort, not the calendar time, that a project will take. Make your estimates in terms of ideal engineering days (often called story points), which are the number of days a task would take if you focused on it entirely and experienced no interruptions.

Using ideal time alone won’t lead to accurate estimates. I’ve asked some teams I’ve worked with to measure exactly how long each task takes them (one team gave me 18 months of data), and even though we estimated in ideal time, the estimates were never accurate.

Still, they were consistent. For example, one team always estimated their ...