In software development, effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input.
Time estimation of software development tasks without statistics doesn’t work. I would also argue that the time, cost, and effort required to estimate and track time with traditional methods are not worth the perceived business value they create.
Unrealistic time estimates and the subsequent perceived date commitments can also incentivize the wrong things. They incentivize speed, which often results to reduced quality, increased defects, missed requirements, rework, unhappy customers and CS staff, technical debt, and additional maintenance cost and time.
Well, estimating is definitely hard in software development. A few good practices which I suggest to get the best estimates of a story are mentioned below:
Estimate in Relative Terms ONLY:
Take a very simple example. You have been asked to travel to Goa from Mumbai by car and you are supposed to give estimate of the time required for your travel!
If I am travelling from Mumbai to to Goa, it would always be better to say that it would take me five times to cover the distance Mumbai-Goa when compared to Mumbai-Pune. Well, you can just figure that relatively by looking at the map as well.
Why am not estimating in hours? I have been told about the places I need to travel – a start point and the finish point. But I have not been told about the mode of transport that I will be using while covering the distance! I could be given a bike or I could be given a car, I could be given a sedan or I could be given a luxury car for the travel! I could be asked to travel early in the morning (when the traffic is less compared to day time), I could be asked to travel at night (when there is less traffic but risk of driving at night).
These things are not known to me when the problem was put in front of me. So I would always use relative estimates as there are many unknowns.
Same is the case with Software development. You have Knowledge, Uncertainty, Complexity and Effort to consider while estimating the total effort needed for any piece of work. It becomes easy to estimate relative based on these four factors.
With relative estimating, the team does not need to think of all of the sub-steps and estimate each and then add them up. They only need to find something similar and use the same estimate.
The next step is to use velocity to determine how long each of those things actually takes. Since velocity is volatile, I like to look at data from at least ten sprints to get a range. Go slow, there are humans at work!
Simple and Manageable Estimates:
Cats and Dogs are easy to manage than an elephant.
It’s always better to keep your (most) estimates within about one order of magnitude, such as from 1-8. We humans are pretty good across one order of magnitude, but beyond that, we are really bad. If the team has a range, it becomes easy for the team to estimate faster and it makes their life simple as well.
Always remember, there are humans at work and they are bound to make mistakes. Nobody is perfect but we can achieve excellence if we keep on trying to improve our ways of working.
