Why Are Estimations So Hard?

Why do we fail at estimations? Can we have a realistic forecast?

Why do we fail to make the right estimations? How did we commit to so n much work.. what were we thinking?

Does that sound familiar? I have been part of multiple teams and in almost every journey I have heard one version of this problem, until of course we finally got it right, well almost. Product development is a complex process wherein the road ahead is not always very clear and we make assumptions and “Guesstimates” to decide our roadmap.

In the end, an estimate is just an estimate, it is not exact. After all, the process is called estimation, not exactimation. — Phillip G. Armour

Uncertainty and inaccuracy are inherent properties of an estimation, being able to measure and manage the requirement uncertainty and the underlying inaccuracies define the character of a good estimate. Creating consistently accurate estimates is often a very arduous process. Most of the time we end up sending a lot more time than we originally estimate or end up delivering much less than we originally thought was possible in that timeframe. I am going to highlight a few of the estimations problems which you just can’t miss:

Optimism Bias:

As humans, even though many of us don’t always sound, but I still like to think we are a very optimistic bunch. We have seen a lot of stuff happen throughout our history, we had the two world wars, catastrophic events like Chernobyl, the COVID-19 pandemic. We still somehow have always managed to be more optimistic than realistic. This giddy optimism is great for the human spirit but not that great for estimations. Last week my son and I decided we need to join back all his messed up lego blocks and bring them back to their original glory. We thought we can do it all in one Sunday afternoon, “How hard could it be, right?… Wrong!”. When you have pieces from multiple sets all mixed together in one giant box of “lego hell”… Let’s just say our optimism didn’t serve us too well. We are still searching for missing pieces.

Parkinson’s law:

“Work expands so as to fill the time available for its completion” — C.N. Parkinson.

C.N.Parkinson a British naval historian in one of his best seller book with the same name has come up with an interesting premise. [1] It’s as simple as this old joke: “How long does it take to do a 1-hour job when you have only 10 mins? The answer is 10mins. But how long does it take to finish a 10min job if you have 1 hour? The answer here is 1 hour.” that’s exactly Parkinson’s law. As you can see this makes a realistic estimation of the task at hand to be nearly impossible. Or as we call, all those things that we can't explain, its more of art than science.

Hofstadter’s Law:

Then comes Hofstadter’s Law, which says

“It always takes longer than you expect, even when you take into account Hofstadter’s Law”.[2]

This is a fun take on the same premise, wherein Hofstadter has demonstrated with recursion the futility of the whole estimation process. It’s really embarrassing, but I have had quite a few situations in my past wherein my team & I had estimated something, increased the estimate halfway through, and still fell short of completing the deadline.

Student Syndrome:

This refers to planned procrastination when for example, a student will only start to apply themselves at the last possible omens before its deadline. This is very close to the 80–20 Principle or the Pareto Principle which asserts that 80% of the outcome results from 20% of the work (your inputs).[3,4] And I wished this procrastination is limited to schools and colleges. It’s quite prevalent in all organizations, causing projects to go over-budget and over-time all the time.

What’s the point if we are never going to get it right? So why do we need estimations? What every product needs is a vision and a realistic roadmap to get you to that vision. The company which can plan closer to reality can have a huge edge over its competitors. News channels provide us with weather forecasts and not weather predictions. They provide a realistic probability of rain this Tuesday, saying it has a 30% chance to rain and not give a prediction which is absolute and Boolean. A forecast is a varied idea of a true value that is unknown. So what we expect from our estimations is to provide us with a realistic forecast and not a prediction of completion. A realistic forecast of features taking into account challenges like unclear requirements, unknown technical challenges, and estimation problems mentioned above.

There are various techniques that can help combat these uncertainties and give the stakeholders and customers a pragmatic expectation of delivery. Project management suggests techniques like 3-point estimates, Statistical PERT, Beta distribution which takes into account the standard deviations for the project uncertainties and attempts to give you a realistic forecast based on your risk appetite. [5]

A lot of Scrum teams use the Story-points estimations technique, wherein each team compares its past history of a similar task and comes up with an estimate for the work in-hand, in Fibonacci series numbers. This very different from the capacity based estimations that we are traditionally used to. And the best part is you don’t have to get it right the first time. Scrum encourages you to do multiple “Inspect & Adapt” cycles to find the right combination that works for you. The number of story points a team delivers in a periodic cycle (sprint) becomes the team’s velocity. And the average of this velocity captured over multiple sprints can be used to forecast the feature completion and design product roadmaps. This technique gives you a range of possibilities. Suggesting that based on the past velocity guideline this particular team can deliver a particular feature realistically around this timeline. One other wonderful thing that Agile does is, it makes you work closely with the customer and gives the customer much-needed flexibility and agility for their product wherein the team can do course correction half-way through the development process to address a business change or consumer requirement. [6,7]

There is no silver bullet to resolve the estimations dilemma. Product development is never easy; it goes beyond individuals, its a team sport and you have the customer changing the rules of the game everyday. But organizations that manage to tame this beast manage to outclass the competition.

References:

[1] Parkinson’s Law — https://en.wikipedia.org/wiki/Parkinson%27s_law

[2] Hofstadter’s law — https://en.wikipedia.org/wiki/Hofstadter%27s_law

[3] Student syndrome — https://en.wikipedia.org/wiki/Student_syndrome

[4] Pareto principle — https://en.wikipedia.org/wiki/Pareto_principle

[5] Statistical PERT — https://www.statisticalpert.com/

[6] Agile — https://en.wikipedia.org/wiki/Agile

[7] Scrum — https://en.wikipedia.org/wiki/Scrum_(software_development)