When it comes to estimating development timescales we are nearly always wrong. Why?
When a developer is asked how long a bespoke piece of work is going to take, they are being asked ‘how long does it take to do this thing you’ve never done before?’ The best we can do is guess based on past experience, a guess for a small piece of work is normally slightly wrong, a guess for a large piece of work, in my experience, is normally exponentially more wrong.
But it’s not just the ‘unknown quantity’ factor wreaking havoc here. There is another element at play, the effect of which is amplified over longer projects causing timescales to drift more and more over time.
My typical time estimation process looks a bit like this:
- Break down the work into chunks small enough so I can accurately guess how long each might take
- Estimate the time to write tests for the above
- Estimate the time to develop the above (normally breaking down into logical sprints)
- Add QA time for each (normally around 20–30% depending on complexity)
- Add the totals up for overall project hours (not to be used for calendar time to delivery)
- Add a ‘something always goes wrong’ buffer (around 10% normally)
We Are Not Machines
The often overlooked element I mentioned earlier is the ‘Productivity Factor’.
An interesting section I read in Managing the Unmanageable
by Micky Mantle and Ron Lichty says that the productivity factor for software development is actually around 60%.
This means that on average a developer is, during their working day, productive for about 60% of the time. The other 40% can be accounted for with distractions, an inability to get ‘in the zone’ and other thoughts which maybe plague their minds. The 40% skyrockets in particularly busy, noisy or generally distracting environments to the point where productivity can be next to zero.
In general I think this consideration is often left unaddressed during estimation because developers don’t want to admit, or tell anyone, that 40% of the time they are not doing anything useful. Moreover, the Productivity Factor is often not accounted for in the project delivery schedule either leading to project overruns which continuously baffle project managers and clients alike.
I nearly always add a buffer to my estimate to account for this (often leading to some irritated reactions) so let me add another step to my above estimation process:
- Ensure an additional 40% Productivity Factor time is incorporated to delivery timelines.
I’d like to hear about how you factor this into your estimates and project plans, and how you think developer productivity is affected. Comment below and let me know your thoughts.