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.
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?
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.
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.
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
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.
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.
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
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.
Dunning Krugger effect: People with different levels of expertise self-perceive their capabilities differently as shown in the graph below.
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.
The planning fallacy is the tendency of individuals to underestimate the duration that is needed to complete most tasks. — source.
Anchoring is human tendency to make decision by adjusting the initial value leading to the final result.
Planning poker is good technique to avoid this.
Are you only considering development time? Are you assuming eight hours per day? Are you adding waste and rework? There are many more.
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.
Decisions follow estimation.