Agile Estimation : An educated guess
Estimating the cost of software is, at best, an educated guess. Although most try to pretend this is not the case, yet despite all the new ideas and models, software is still costed in the same way it was 20 years ago. Due to the complexities involved in software cost estimation, it ultimately relies on the judgement and informed opinion of the team.
A typical software estimation process follow the given procedure:
1. Deconstruction of the software based on functional boundaries is carried out and the result is often a requirements document. Given the nature of human understanding, this document is usually a ‘best first guess’ of what the client had in mind.
2. Programmers estimate how long it would take to build each component.
3. Some contingency factor is then applied. This contingency factor (also known as ‘transactional complexity’, or ‘risk assessment factor’) are gross multipliers often by up to +/- 150%.
The result is a crude software estimate that can vary by +/-50% of the final cost. This is such a large margin of error that it is considered as a good guess and nothing more. In comparison to a real science, we know the speed of light to an accuracy of plus or minus one part in 300 million.
Estimating the total cost of Agile projects
Agile methods have matured and are now being integrated into many different approaches to the development of software. Estimation has been problematic for all methods; agile to plan based therefore it tends to be a lightning rod for experimentation and synthesis. Agile Estimation Using Functional Metrics has presented a path for integrating the discipline found in functional metrics with the collaborative approaches found in agile estimation.
Questions about how to estimate the total cost of Agile projects are actually about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous.
How would a team estimate the cost of fixed-scope work upfront? Here are several approaches for you to consider:
Estimate the project the same way you currently do. If the approach that you’re using provides enough accuracy and you’re able to make a profit, then why change? Any other approach is as likely to be as inaccurate as what you have now.
Estimate the project using a coarse scale.. such as garment sizing, and then assign a price range to each size. For example, have the team work with the product owner to create a list of User Stories at a high level. The team then estimates these on a very coarse abstract scale such as T-Shirt sizes ranging from XS through to XL
