Estimation Does Matter

  1. Posted on April 20, 2009 11:17:AM by Earl Beede to Practicing Earl
  2. Technique, planning, estimation, Management

Recently, Mark over on the Agile Project Management Yahoo discussion list posted this little remark.

“A feature will take *exactly* the same amount of time whether the
estimates are "good" or "bad"!

“I swear I'm going to print that on a 10 foot banner and hang it over
my desk for our entire organization to see.

“As a community, I believe we spend way too much time talking about estimation. A "good" estimate is never going to get a feature done sooner.

“Instead of spending time talking about estimation, we should be focusing on the other engineering practices, e.g. specification driven development, continuous integration. At least they have a positive impact on delivering value.


The question to ask is, “Is this true?” Does a feature take the time it takes regardless of how much time we think it will take? That is, if I have a feature that in its essence is one week worth of work and I estimate that the feature will take more than a week to develop or less than a week to develop, it will still take a week to develop, regardless of the estimate.

Or, more simply, does the quality of an estimate, its “goodness” or “badness”, have any impact on the work?

The first shot at saying that the quality of the estimate does have an impact on the work is Cyril Parkinson’s observation in a 1955 Economist essay: “Work expands as to fill the time available for its completion,” commonly known as Parkinson’s Law.

If we were to give my one week feature two weeks to complete, Parkinson’s Law would suggest that the feature would end up taking two weeks regardless of its nature.

Now, I am sure that there is some limit to Parkinson’s Law. If I gave my one week feature ten years to complete, it would most likely not take the ten years. However, it is just as likely to take more than its innate week.

Why do we hold Parkinson’s Law true? Mostly, it is an observation of our collective experience. We can think of trivial examples such as students putting off papers until they are almost due, a lowered sense of urgency while doing the work, increasing the amount of “polish” or tuning we do rather than stopping at “good enough”, etc.

Add to that the planning errors we make. Since I estimated my one week feature would take two weeks, I did not think I could get a second one week feature in this work period and set that second feature aside.

What is the impact of that? The answer depends of course but picking up that feature in the midst of my work period means that the tasks to incorporate that work must be picked up at a point that may not be optimally designed for doing that kind of task. Instead of discussing the feature with the customer who was present at the initiation, I must track the customer down and hold the same discussion, now out of context. Just that extra work of getting the customer, explaining the situation (the first feature was done in “half the time”), and then doing all the tasks I would have done earlier if I had a correct estimate makes the second feature take just that much longer than it inherent nature.

So I think Parkinson’s Law holds true enough for overestimation. What about underestimation? Is there an impact to the work when we estimate it at less time that it really needs?

I think that the answer here is also a definite, “Yes!” Several things conspire to actually increase the amount of time needed to build our one week feature. Some of that increased time is realized on the current work, some of that extra time is taken on as technical debt.

The current increase to my one week feature comes from planning errors and schedule pressure. When I estimate it will done in two days rather than the one week of its nature, I make plans based upon that estimate. Some of those plans involve coordinating activities with other people and resources. When I can not meet those coordination points due to my work taking longer, those plans need to be changed. If the people and resources are the typical in-demand things that they are, then it will take more time to establish new coordination points thus increasing my work on the feature. At the least, I have had the extra work of establishing the coordination points twice.

Steve McConnell also documents in Rapid Development that just the feeling of schedule pressure can drive up defects. We make more mistakes when we believe we don’t have the time to do the job as it needs to be done. These defects take time to correct and, thus, increase the schedule for my one week feature.

Some of the increased time to complete the feature can be deferred as technical debt. Rather than repeat my post on the sacrifice of non-functional attributes to meet schedules, I will note that we can meet almost any schedule if I am allowed to “relax” non-functional attributes of my feature. However, these relaxation of things like “maintainability”, “portability”, “readability”, “usability”, etc. are likely to come back in future feature work and increase the time then.

This concept of estimates having an impact on the work is nicely summarized in a poster that my employer, Construx, offers.


On the right we see the linear impact of Parkinson’s Law; on the left, the non-linear impact of planning errors and technical debt.

It seems Mark may be taking a simple case. However for most of us, the quality of the estimation does have some impact on the time required to complete a feature.

awiesendanger said:

April 28, 2009 12:12:PM

Hey Earl, nice explanation of why bad estimation is a problem that affects value. But what about not estimating at all?

Earl Beede said:

April 28, 2009 12:52:PM

Wow, do you think that is even possible? While it is probably very possible to not publish or state an estimate, don't you create a mental estimate regardless?

bigboxshops said:

June 3, 2009 9:36:PM

good explanation of  bad estimation , it is probably very possible to not publish or state an estimate?

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl