Time estimations are hard! Even Douglas Hofstadter says so:
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
In fact where time estimations are involved even hindsight isn’t 20/20.
Part of R&D’s responsibilities is to are the last line of defence support, if a problem stumps Support they will escalate it to R&D. However support is not considered to be a developer’s main goal in life and it’s useful to know how much time developers spend on support so as to be able to plan ahead.
This feature should take 6 man-month to develop, we have 3 developers but they spend 10% of their time on support so it will take 9 weeks rather than 8.
But how can we know how much time is spent on support?
When we rolled out our escalation management system we added a step at the end of the process in which the developer estimates how much time was actually spent on this case. We soon saw that the numbers appear to be very low for several reasons.
- Escalations typically have several iterations of getting more information from the customer and this may span weeks (or months if the customer has more important things to do) making it very hard to remember how much time was actually spent on the escalation.
- If an escalation is re-assigned the time spent by the first (N-1) developers is lost.
- In some cases the escalation was closed before the developer had a chance to fill in the data.
In order to combat all these problems we made the time spent on escalations accumulative, every time a developer moved the ball into the supports’ court (asking a question, sending a DLL) a mandatory field asked how much time was spent on this iteration.
Suddenly the estimated time spent on escalations went up, it would appear that when trying to recall how much time was spent doing support R&D tended to underestimate by about 40% (the actual number I got was 42 but that’s just too good to be true).
These data  are problematic since they contain the unrelated set of escalations that were closed before R&D filled in the time spent and the lost time of developers other than the last one. Putting that aside what we can see from the graph is that retrospective estimations tend to underestimate time that was spent treating an escalation. The peak at zero is probably to do with the causes mentioned above but we still see that on average the estimations are lower than those gathered when incidents were fresh in memory.
This is just one data set, I would be interested to know if there are other such data available.
Maybe this has something to do with the notorious difficulty people have in estimating how much time something will take, if you can’t remember how long a similar task took how can you be expected to learn from past experience? Perhaps if we kept better track of our time we would slowly learn how to make better estimations, even those about the future.
 I’ve omitted the long tail of escalations that took more than 8 days since they add little to the general picture. ↩
 Zero days is not obviously an error, time is measured in hours and then converted to work days. Therefore any amount of time up to 4 hours will be shown as 0 days. Even when accumulating the time we see that the highest proportion of escalations were solved in 0 days although this slice is half as big as any other. ↩