Evidence based analysis of task estimates

[Derek-Jones]

What evidence do you have that developers are no good at estimating?

Estimating is certainly an unpopular activity. But let's not confuse popularity with accuracy.

Analysis of time based estimates shows around a third of software task estimates are accurate, 2/3 are within a factor of two, and 95% within a factor of four: data+analysis

Detailed analysis of one company's estimation data, and analysis of estimates from 40+ individual projects.

Do you have any estimation data that can be shared?

[stebunovd]

Hi Derek, and thank you for your comment!

I suppose it highlights an area in which the article needs improvement. I didn't mean that developers cannot produce reliable estimates, but I probably wasn't clear enough. My point is that estimates harm development productivity for three main reasons:

1. The only way for developers to provide more or less reliable estimates is to over-estimate, and they quickly learn to do it. What happens next is work slowdown due to Parkinson's Law;
2. Estimates can create dangerous misconceptions, such as people focusing too much on the initial implementation estimate and not considering longer-term support, which could be huge;
3. Finally, the estimation process takes its own time. It's not free - producing an initial estimate, debating on "why it takes so long," correcting an estimate when requirements change, and then discussing why it was missed and what to do next (the usual solution is to ask for more estimates);

This is certainly possible to achieve predictability in software development, but the tradeoff would be the development speed. Embracing some level of uncertainty could help teams move faster, and it doesn't mean an absence of planning. Splitting the project into phases, time-boxing research phases, frequent releases, the "fix time, flex scope" approach, and other techniques could make it perfectly manageable.

[Derek-Jones]

Thanks for the detailed reply.

Developers probably do have some idea about how long a task will take, but dislike giving numbers.

The extent to which Parkinson's law has an impact on performance depends on how management treat developer estimates.

Estimates are part of the conversation around planning; estimates are not set in stone. Now, some managers treat estimates as set in stone, which causes developers to overestimate and behave in various unproductive ways.

Estimating a very large task is likely to require a lot of time. So what? Obtaining the information needed to make the estimate is part of the process around evaluating the work needed for the task.

Developers don't like making estimates, and in the past management may have pandered to this dislike, fearing that otherwise developers will leave.

Now a recession is coming, developers will find it harder to get another job. Perhaps estimating will become more common.