Do You Have Issues Estimating Projects?

Estimating

Universities have conducted studies to determine the accuracy of estimates versus actual time taken to complete tasks. They concluded that tasks take, on average, over twice as long to complete compared to the estimates. Optimism and not considering potential issues and blockers contribute to the problems with underestimating.

The studies found that people are able to estimate other people’s tasks more accurately than their own. Not using historic data to assist with estimating is another cause of poor estimating.

Overview of estimating

The following points will help when you are estimating effort for a project:

• Set a provisional estimate for each task.
• Use any historical data to assist with the estimates.
• Factors to consider include the number of people on the team, their level of experience, how complex the development is, integrations, etc. 
• Studies have indicated that most activities take over twice as long as the estimates. (This is across a range of industries, but it definitely applies to software development.) 
• Peers with relevant experience are usually better at estimating than the individual who will actually perform the work.
• People on projects may overlook blockers that could result in the tasks taking longer than anticipated.
• Allow extra time if the team needs to use any new tools or processes. (Doubling the estimate is not unreasonable.)
• Don’t schedule people for more than 80 per cent of working time to account for holidays, illness, etc.
• Integrations can be difficult, and completion may take far longer than anticipated. Always try to finish integration builds and test activities as early in the project life cycle as possible.
• Security configuration and testing can be difficult and time-consuming. Third-party security testing companies usually have a backlog of work, so it’s good practice to agree on tentative dates as early as possible. Furthermore, remedial work identified during the security test(s) may take a considerable amount of time to complete, especially if the work requires updates to major infrastructure components.

Estimate the timings for the complete project

• Use information on individual tasks and knowledge from previous projects to estimate the time required.

The following is not an explicit part of some methodologies, but it is worth mentioning in regard to estimates for the project. Don’t forget to include the relevant activities in the estimates and overall timescales:

• Project warranty after go-live.
• Business process and cutover dress rehearsal activities.
• Cutover activities.
• The tasks necessary for the transfer to the support team.
• Super user training and support.
• Communications.

Estimating in a Scrum environment

• The planning meeting should include the entire Scrum team. In fact, everyone that could assist with planning should take part in the meeting.
• Anyone with specialist knowledge that can contribute should also attend. An example would be estimating a backlog item that has a dependency on a security change. In this case, invite someone from the security team to the meeting. The security change may require work the development team wasn’t aware of. 

Think of all the dependencies the Scrum team has and include representatives from the teams in the planning meeting.

Estimating backlog items

There is debate about when estimates for the backlog items should be completed. I’ve found that it is beneficial to estimate them as early as possible and as far forward as you can. This allows you to sanity check the total effort required for each phase and the complete project at any early stage in the lifecycle. It also highlights areas where there are unknowns. For instance, the team may be working on sprint one while implementing a new API in sprint four. There may be a high level of uncertainty about the effort required to implement it. By looking forward, you can identify the unknowns and gather additional technical information. This improves the accuracy of the estimates and helps mitigate delivery risks.

There are different methods a team can use, including T-shirt size, points, affinity mapping, dot voting, bucket systems and others.

Contingency

• Remember that activities take, on average, twice as long as estimated. Keep this fact in mind when you are preparing the plans. 
• It’s always beneficial to include contingency in the project budget. 
• Increase the contingency appropriately if you have several unknowns.

In summary, ensure you do everything possible to estimate projects accurately. You do not want to go back to the stakeholders multiple times for additional budget. Good luck!