Guidelines for Software Estimation

Software estimation is an art which, if done correctly, can result in an enjoyable project which delivers commercial benefits without cutting corners and makes the customer/sponsor of the project happy. If done poorly, it can result in a nightmarish project which never seems to end, is full of defects, and makes all stakeholders in the project, especially the development team unhappy and stressed.

Let's remember that if an accurate estimate is so high that the project or product is no longer commercially viable, it probably wasn't viable to begin with. Knowing that earlier, rather than later, does everyone a favour. The best time to cancel a project is before it starts, rather than half way through.

In my experience the challenges to meeting a project deadline come from three areas:

• Unrealistic deadlines enforced on the development team
• Unexpected/unplanned activities (including scope creep)
• Technological challenges which take longer to overcome than originally anticipated

Below are some guidelines which have helped me to avoid the nightmare scenarios:

• Break the project up into a series of well-defined, measurable tasks or user stories.
• Get the developer or development team who will be doing the work to do the estimation - that provides ownership of the estimate.
• If the estimate is greater than 5 days, consider if the task can be subdivided into smaller tasks. An estimate greater that 5 days is likely to be quite inaccurate.
• If the estimate is less than 1 day, consider bundling that task up with others. A 'half day' estimate is not likely to be accurate.
• Believe the estimates supplied by the development team. You can alter or push them into altering the numbers they give you, but chances are that it will take as long as they initially said anyway.
• Multiply development estimates by 1.3. Developers are generally optimists at heart. Metrics I have run post-project have shown me that, over all, developers generally underestimate and a modifier of 1.3 brings the numbers much closer to what the actuals.
• Create a feedback loop for yourself.  Between sprints, iterations or projects review actual versus estimated effort for different types of tasks (web pages, web services, background services, database etc.).  Use this to identify your own estimation accuracy modifier and investigate reasons why particular tasks went significantly over time or under time.  Put these in a lessons learned list to refer to next time around.
• Prototype technical unknowns and assign separate time-boxed tasks for these to inform your estimation of the actual task.
• The most common reason for extending the schedule is not including particular tasks.  Walk through your entire task tree from requirements, through development to release and deployment.  Ask yourself "What am I missing?".
• Don't forget non-development tasks eg. setting up and maintaining nightly builds and continuous integration, creation of knowledge base articles for the support team, set up and configuration of the deployment environment etc.
• Where possible, do estimation as a team.  Tasks or steps one person will miss, others will pick up.
• In addition to scheduling testing, also schedule time for the resolution of defects found.
• Make sure you do "resource-leveling" and identify and monitor the critical path for the project.

I will add to this list over time.  Hopefully you will find something here that will help you improve your estimation accuracy.