Stop Comparing Actuals to Estimates!

The imprecision of the communication from customer to salesperson to marketing to development to a designer to a coder to a tester to a system that does what the customer wants is immense. The estimates are often a translation of wild guesses made during this conversation. They reflect at best a guideline for the solution based on past work or similar projects. But it does not account for the impact of new technology, a different team skill-set and capability, or a different business domain.

Organizations will often focus on improving their estimation performance by building databases of estimate versus actual development metrics. Don’t compare actual to estimates! This will cause teams to focus on delivering within the tolerances of previous estimates. This often leads to an undesired effect; a compromise on quality, standards, re-factoring, database rationalization or other value added results of delivering quality, demonstrable functionality on time. This is the effect of sub-optimal measurement; measuring one single metric without paying attention to the larger holistic picture.

Increasing the accuracy of estimating by comparing actual hours worked to estimated hours worked is a suboptimal measurement. Comparing what the Team actually produces to a desired release date and release goals is a much more appropriate measurement.

What can teams do to improve the estimation process. Effective retrospective debriefs at each milestone, iteration checkpoint, or deliverable often will uncover the real challenges the team is facing. By learning and sharing the team will determine the true capacity to do work (velocity) of the team. And they will collectively become better at estimating the effort required to complete new units of work. Comparing to the actual metrics of past projects is comparing apples and oranges, and will not ultimately deliver the intended results.