All too often in software development, we are asked to provide estimates for upcoming pieces of work. Invariably, these estimates are then incorporated into a plan, which is then taken as gospel to be the timeline for when the feature will be delivered. Should the feature not be delivered on said date, then the question is asked are :”Why is the feature late?”, but that’s asking the wrong question. The right question is “Why were the estimates taken a firm dates?”

There are many factors that go into providing an estimate for the duration of a task, but ultimately, unless the task is well defined and there is a record of the time taken to implement similar features, the estimate will have a high margin of error. Unfortunately, Gantt charts can’t cope with margin’s of error, so the times fed into it are seen as absolute. Everyone is happy because there’s now a nice little graphical representation of how the project will progress, it can be tracked, and people can tick boxes and sign off on it.

Everyone is happy… except the developer. His stated caveats, concerns around the lack of prior examples, concerns about the research and exploratory nature of the tasks, are all ignored. Result is that the developer will either have too much time (leading to questions), or too little time (leading to a lot late nights), and will end up dying a little more inside having to deliver the feature to a enforced timeline.

Inaccuracy in estimates can be caused by many things, though some common examples include:

• Not estimated by the developer doing the work
• Estimated before enough detail is known
• Task is not of fine enough grain to be visualised and estimated
• Lack of prior art and estimates v.s. reality for similar features
• No allowance for unforeseen circumstances
• Lack of understanding of just what the feature is supposed to do or how it would be implemented

etc…

Estimating the complexity level of a particular feature is the best that can be achieved at the point where software features are typically estimated. Estimating duration/effort is usually going to result in the output of a random number generator.

The only way that I have found to get some semblance of a reasonably accurate estimate is to get the developer who’ll be implementing the task to estimate how long it would take just before they commence on the task (i.e. when all the requirements are in place, etc). It doesn’t fit well with charts and long term plans, but it does have at least a level of accuracy.

It’ll be done when its done.