The main objective of this chapter is to present software estimation techniques that are easy to apply. Experts have been writing about software estimation for more than four decades (Shepperd, 2012). They have developed numerous techniques for software estimates. However, the knowledge does not make a person an expert estimator. There are numerous problems that arise during the estimation process (Jørgensen, 2004). Small teams need to use simple but effective techniques. The problem is to combine these simple techniques with low deviation.
Software estimation research is focused on improving techniques in order to reduce estimation deviation (Jorgensen, 2009). Software projects are influenced by numerous factors that are embodied in complex algorithms. Software practitioners do not have the time to learn the intensive mathematical support required to understand estimation models. In software engineering, as in similar disciplines, perhaps the most stable result is that simple models typically perform just as well as the more sophisticated models.
This paper emphasizes techniques, procedures and simple formulas that are directly used by software practitioners.
1.1 Estimation Challenges
Effort estimation for software development depends on limited understanding of requirements, often complicated, but uncertainty is derived from requirements changes and lifecycle progress. Although idiosyncrasies in projects drive effort estimations, differences in organizational capabilities further affect the validity and reliability of these estimations.
Traditionally, estimation is a critical activity in developing project economics to determine if a project is a sound investment (Sommerville, 2004). But, in Agile environments, estimation is a way to create a shared understating of the requirements, and a shared understanding of the solution (Cottmeyer, 2011). When teams have problems estimating, it is almost never an estimation problem, but rather a shared understanding problem. Some of the most common problems relate are on the product side as insufficient understanding of business problems, insufficient requirements decomposition and insufficient business involvement. Other understanding problems come from technical debt, quality, or even just teams that are unfamiliar with the technologies. All of these problems result in making estimations without a clear understanding of what needs to be done. In order to achieve better estimates, it is necessary to generate a shared understanding.
One way is to develop an estimation process focused on four key attributes (SQCC, 2011):
- •
Credibility: The estimation technique must be visible and provide assurance that the best possible prediction has been made.
- •
Confidence: Estimates provided at particular points in the life cycle have a proven probability of being correct and a proven variability.
- •
Control: Actual results can be compared against selected estimates as part of the measurement process. Problems and potential problems can be identified and addressed before they have an impact on commitments.
- •
Continuity: A well-defined estimation technique and well-documented results allow personnel to understand fully the basis of the previous estimates and to identify areas which have changed since the original estimates were produced.
Normally, these factors rely on collective knowledge. However, the quality of organizational databases of lessons learned varies greatly. Although the databases generally contain volumes of technical data, they are unmanageable because of the sheer quantity of data. Another caution for using data from previous projects is that the context for the historical number is not fully understood.
Another aspect of estimation is understanding the risks that could affect a project. Teams have a limited pool of projects to assess the reasonableness of estimates and overly narrow perspectives of what risks could emerge.
A human aspect is the lack of specialized skills for performing estimation (Jorgensen, 2007). There is very little estimation talent in the industry. Much of the new talent entering the software industry is focused on technology development.
And finally, there is a deadline driven culture, where the estimation results are often used to manage only the scope, ignoring commitment and shared understanding.