Underestimating Estimation

Use estimation for making decisions and not customer commitments.

Imagine

How much time would it take to carry a box from A to B as in the figure below?

With a team of eight people, how much time would it take to carry a big box in the Himalayas?

Here is the final problem to estimate, “You are Columbus, and you have a team of twelve people. You need to find a new island. You have some experience in exploring and finding islands. And the team is distributed.” It sounds closer to software project estimations. Change is constant— technology, people, requirements, business. Any estimate done for more than two weeks is quite uncertain.

Sydney Opera House — 10 years delayed, 1,457% over budget

A HBR article shows, ‘one in six IT projects has a cost overrun of 200%’. It is a big failure of estimation. Then why do we estimate?

Why estimate?

The process is called estimation, not exactimation. — Phillip Armour

For the given understanding of the scope, expected outcomes are time and cost. Just like a travel estimate helps in trip planning, estimation acts as a useful tool for decision making and planning. Decisions and plans are bound to change. Eventually, it sets a direction and buys commitment.

It also helps to plan for coordination. If a project B is dependent on project A, it gives an overview of wait time.

Napoleon allegedly said that no successful battle ever followed its plan. Yet Napoleon also planned every one of his battles, far more meticulously than any earlier general had done.

Balancing the four constraints

There are four primary constraints of estimation as defined by the iron triangle — cost, schedule, scope, and quality. I would like to represent it like a balance.

The four constraints of estimation

If you want to increase the scope, you either have to raise schedule or increase cost or reduce quality. The balance has some practical limits.

If 100 people can build a bridge in 100 days, can 10000 people build the same bridge in 1 day?

Cost and schedule are easy to measure. Quality is relatively hard, and scope is hardest to measure. Projects should promote changes but manage scope. On an overestimated project, if a choice has to be made between reducing scope versus reducing quality, it is better to choose the former. Also, the scope can be decided based on customer value.

Factors underestimating estimation

• How much are you done when you are 90% done?

Ninety-ninety rule: The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — Tom Cargill, Bell Labs

With 90% of work done, the remaining 10% is refining the requirement, misread details, small UI-UX tweaks, blockers, code-review comments, build failure, etc. This 10% is highly underestimated and consumes significant time.

Ninety-ninety rule

• Are we all using the same scale?

We estimate by sizing the tasks or relative sizing or by hours taken by a person, etc. It is essential to understand that all of these have some assumption of scale. For instance, the interpretation of a persons capacity is different, by different people.

Assumption of a persons capacity

• Is the estimate pleasing?

Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality, or reality. It is a product of resolving conflicts between belief and desire. — Wikipedia

• Are you trying to appear nice in the group?

Groupthink is group decision making by avoiding conflicts by suppressing right opinions or by not evaluating alternate options. Similarly, polarization is the influence of people with stronger personalities dominating the estimates.

Avoiding conflicts by suppressing true opinions

• What is the distribution of expertise in the group?

Dunning Krugger effect: People with different levels of expertise self-perceive their capabilities differently as shown in the graph below.

Dunning Krugger effect

Less experienced ones are not aware of their knowledge and rate themselves more. People with moderate experience are aware of things that they don’t know and rank themselves less. They rate others more. It affects estimation.

• Planning fallacy?

The planning fallacy is the tendency of individuals to underestimate the duration that is needed to complete most tasks. — source.

• Is the first estimate influencing the group estimate?

Anchoring is human tendency to make decision by adjusting the initial value leading to the final result.

Anchoring influencing estimation

Planning poker is good technique to avoid this.

• Miscellaneous

Are you only considering development time? Are you assuming eight hours per day? Are you adding waste and rework? There are many more.

Concluding thoughts

Estimation has a reputation for creating wrong expectations. We discussed many reasons why it cannot be accurate.

Wrong estimates may not be the reason for delays in projects. Using it as customer commitment may be the problem.

As the development progresses, customer value becomes more evident. Estimation should not restrict agility.

With the available people, time, and capital, estimation acts as a tool to choose the direction.

estimation as a decision making tool

Decisions follow estimation.