Keep software estimates "ball park only", otherwise don't estimate at all!

In nearly all cases, as software developers we must give estimates on how long a piece of work is going to take to complete. Even more, when we have medium to large problems to solve, we often have to break down the problem into smaller chunks of work. We may have to then "embed" these pieces of work into a project plan. Who works on each item?, How much of these items can be done in parallel?

And we conform to this, we give estimates, the project plan is complete and the problem solution is completed exactly how we planned and estimated, right?

No I'm afraid that is not how things work. From experience, I find that the solution rarely gets completed when it was estimated to do so (or near enough when it was estimated to do so). It gets completed either before or more commonly sometime after. Reasons can be as follows:

• Other work, previously unaccounted for is required that we only encountered when we were down in the detail
• Other work external to the current work is prioritized
• Members of a team become unavailable (e.g. other priorities/sick etc)
• Numerous other reasons

So, why estimate at all?, Well we have to estimate to enable business stakeholders and project managers to make decisions. So I have a solution that I have seen that works...

Estimate ball-park level only. From experience I have seen that this always works, we always hit the jackpot. I have found that estimating at this high level has no exact science, it is often in some cases based on instinct but it always seems to prove accurate enough. Having a micro-management process for estimating pieces of work will prove inaccurate anyway, cost money to run and prove cumbersome to the team trying to adhere to it. If you micro-manage you are probably better off not estimating at all!

Low ceremony process with high-level "ball-park" estimates is the recipe to success!

Billy