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”
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.
- It’s a target. No, A target is a Statement of a desirable Business Objective. And objectives are not something that helps our leadership in planning for release, marketing, etc. Below are some examples of target statements.
“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.”
- So, It is a timeline. Well, it is neither a timeline nor a deadline. Timeline is a representation of a period of time, on which important events are marked. This doesn’t seem like a quantifiable thing. It looks more like the things that we do after estimates.
- Maybe it is a commitment then. Commitment is a promise to deliver defined functionality at a specific level of quality by a date certain. Same as estimates but more aggressive than it. Nobody should commit if they can’t fulfil. It is about certainty. The stakeholders would accept your commitments and make their plans as per those. The cost of missing your commitments is way too high as it impacts your stakeholders’ plans and takes a huge toll on your reputation too.
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.
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?
- One super positive guy who carries some specific knowledge (or a hint of overconfidence), might say 1–2 hrs.
- Another guy who is a specialist in relevant tech and domain might say 1 day, considering a decent amount of risks.
- Some other guy who might be sceptical about things might give an estimate of 3–4 days.
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.
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.
μ = (O + 4N + P) / 6
σ = (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
- The Law of Large Numbers — whenever you have a large number estimate, break it. The accuracy in estimates is more when the estimates are done for smaller tasks and hence in small numbers. So for an example, if we have an estimate that is more than 4 hours, the task should be considered to be broken further. Some of the probable mistakes in estimates would integrate out, and breaking the tasks into smaller ones is a good way to understand all those tasks better and avoid surprises.
- Cone of Uncertainty. This concept says that we have a lot of uncertainty at the start of the project so chances of going off around the completion are high. So evaluation multiple times during the timeline of the project whenever we get to know new things. This also helps in ever-changing software requirements.
- One Bite at a Time (a.k.a. How to Eat an Elephant?). A cliché practice for large projects. Divide and conquer is another name for this. Break the project into small parts to evaluate and work.
- Déjà vu. We should keep a historical log of how long it took for our team to complete tasks. Also, recording important metrics such as the number of function, components, UI item, or maybe lines of code. We can use this log as a guide in future estimates.
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.