Deciphering the Art of Estimation

Meet Gupta
Sep 6, 2019 · 7 min read
Creative by — Team Tokopedia

Estimates. This is quite a common term used in all sort of areas of work in businesses. And when it comes to us, the Software professionals, it is used so much that it is safe to say overused. How dare I say it is overused 😬. It is supposed to provide decision-makers with some vital information that helps them make better and smarter decisions. But, are we sure what exactly it means?

Let’s elucidate “Estimates”

This is what everyone thinks

In my 11 years of experience, I discussed this with many people. But since it is not something that is taught to engineers in their academics so everyone has their “own” definitions for it.

“We need to have Version 2.45 ready to demonstrate at our town hall in Sep.”

“We need to have this release stabilized in time for the Festive Sales.”

“These functions need to be completed by Oct 1st so that we’ll comply with regulations.”

But

Now, what exactly is an estimate? If you google it, you would find many dictionaries defining its meaning and there would be some pages that would tell you what people mean when they say this magical word — Estimate.

A tentative evaluation or rough calculation.

A preliminary calculation of the cost of a project.

A judgment based upon one’s impressions; opinion.

An estimate is a guess. No commitment is implied. No promise is made. Missing an estimate is not dishonourable in any way.

Ninja technique of estimation

So now when we know what an estimate is, is it good enough? With the above explanation, lots of estimators get off the hook because it is a guess.

It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.

— Fred Brooks

Business is not something that runs on guesses or some rough calculations. So let’s find something called — A Good Estimate.

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets Steve McConnell (Software Estimation: Demystifying the Black Art)

How do we do it

Some say that it is an Art, it grows on you. Whereas some people perceive it as science based on some assumptions. But actually, it is maths.

Let’s try to estimate a small problem statement. A simple view which would have a button on it and on click of that button, we would make an API call and show success/error response in a popup. I just tried to make up an example so don’t judge me for it. Now the question is — How much is your estimate?

There would be more guys having different estimates. This enlightens us with the fact —

An estimate is not a number. An estimate is a distribution.

There are many theories out there which try to solve the estimates with probability. I am going to discuss one of them — a very famous one.

PERT — Program Evaluation and Review Technique

This technique was created in 1957 to support the U.S. Navy’s Polaris submarine project and one of the many elements of PERT is the way the estimates are calculated.

🚨Mild Maths Alert🚨

This technique suggests that we should take three kinds of approaches to find three different estimates, to reach a good estimate.

O: Optimistic Estimate
This number is wildly optimistic. You could only get the task done this quickly if absolutely everything went right. 1% chance of occurrence.

N: Nominal Estimate
This is the estimate with the greatest chance of success.

P: Pessimistic Estimate
Once again this is wildly pessimistic. It should include everything except hurricanes, nuclear war, and other catastrophes. 1% chance of success.

Now let’s get values for two important values — Distribution and Standard deviation.

Probability distribution

μ = (O + 4N + P) / 6

Standard Deviation

σ = (P − O) / 6

So for the above example, the values for O = 2 hrs, N = 8 hrs, P = 24 hrs (considering 8 hrs per day). So μ would be 9.67 hrs and σ would be 3.67 hrs.

So it is highly likely that the work would be done in 9–10 hrs with a possible deviation of 3–4 hrs. You can take this σ as a buffer so it can be considered as 2σ too if there is some learning curve.

If we are doing this for more than one task or subtasks then following formulas would be applicable.

How do we get those magical numbers

Wideband Delphi is one of those techniques to find these numbers. In the 1970s Barry Boehm introduced us to this estimation technique. There have been many variations over the years — formal or informal; but they all have one thing in common: consensus. We will discuss some of the variations here.

Flying Fingers. Have your estimations on fingers but don’t show your fingers. The moderator will request the participants to estimate the task. Each participant would estimate independently and keep the numbers on your fingers. They should hide the fingers under the table and when the moderator asks, all the participants wave them in air.

Planning Poker. The same approach but with numbers on the cards. This is probably the most popular variation.

In both of the above techniques, the numbers can be chosen from 1,2,3,4 or Fibonacci series or T-shirt sizing. If all are similar, you can keep the average but if you have some uncommon estimates, discuss among the participants.

Affinity Estimation. All the tasks are written onto cards or papers, without any estimates showing. The estimation team stands around a table with the cards spread out randomly. The team members do not talk, they simply start sorting the cards relative to one another. Tasks that take longer are moved to the right. Smaller tasks move to the left. Once the sorting is done the discussion starts.

Reminder to some common practices

Source: AgileNutShell.com

There are many other techniques as well but applicability varies and many of them are just theory. So till we get a silver bullet for the curious case of estimation the above techniques should serve your purpose and might get you from (+/-)20% success to (+/-) 5% accuracy.

Cheers!!🍻

Tokopedia Engineering

Story from people who build Tokopedia

Thanks to Ravi Aggarwal

Meet Gupta

Written by

iOS Apps Artisan. Freelancer. Engineering Manager @Tokopedia, Ex @Shuttl_Ind, @Fab, @Paytm. Passionate about photography, cycling, roaming and outdoor sports

Tokopedia Engineering

Story from people who build Tokopedia

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade