Software Project Effort Estimation PDF

Challenges of Predictable Software Development 1 Failing to plan is planning to fail. —Winston Churchill Effort and cost estimation are of pa...

Challenges of Predictable Software Development 1 Failing to plan is planning to fail. —Winston Churchill Effort and cost estimation are of paramount importance for the success of software development projects. Everyday practice shows that many software organizations still propose unrealistic software costs, work within tight schedules, and finish their projects behind schedule and budget, or do not complete them at all. In this section, we introduce software effort estimation as an essential element of a successful software development project. We look at the characteristics of software and the software engineering environment that make estimation a parti- cularly challenging task. Finally, we try to answer the basic question of estimation, namely, “what is a good estimate?” 1.1 Software Is Getting Complex The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line. —Terry Bollinger Software is everywhere. Most of today’s goods and services are realized, at least partially or completely with the help of software systems. Our dependency on software increases continuously. On the one hand, progress in the domains where software has traditionally been playing a key role entails increasing pressure upon software to progress. On the other hand, in domains that were traditionally reserved for hardware, software has become the major driving force of overall progress. For example, it is said that 60–90 % of advances in the automotive domain nowadays are due to software systems. Some products and services that would have tradition- ally been realized through “hardware” solutions are now realized through software systems. Other products and services are only possible through software systems A. Trendowicz and R. Jeffery, Software Project Effort Estimation, 3 DOI 10.1007/978-3-319-03629-8_1, # Springer International Publishing Switzerland 2014 4 1 Challenges of Predictable Software Development and could not have been realized by other means. In this way, the size and complexity of software systems in various domains has increased rapidly. This increasing complexity of software systems entails a fundamental shift in their cost, time-to-market, functionality, and quality requirements. Software is required to support a wide variety of domains; must always be faster, more intelli- gent, more dependable; must require less hardware resources and be ever easier to maintain; and, and, and. The wish list is typically quite long and ends up with: “The software must cost less and come to the market before our competitors even think about something similar.” 1.2 Software Development Is Getting Complex Better, faster, cheaper. Choosing to concentrate on two of these concepts made accomplishing the third difficult or impossible. —James E. Tomayko and Orit Hazzan When looking at the traditional manufacturing disciplines, software practitioners may ask themselves: “If most manufacturing industries are able to control cost, schedules and quality—at least most of the time—why can’t we?” One simple answer is: “because software development differs from classical manufacturing.” Let us briefly go through several aspects that distinguish software development from traditional manufacturing. Development Technologies and Paradigms Change Rapidly. Software devel- opment teams must strive to achieve software development objectives by exploiting the impressive advances in continuously changing—and thus often immature— technologies and development paradigms. In fact, mastering rapidly changing technologies and processes is often considered as the most important challenge differentiating software development from other domains. Without counting the minor changes in methods and tools, throughout the past 50 years, the software industry has roughly gone through at least four generations of programming languages and three major development paradigms. Development Distribution Increases. Together with the increased variety of software products, technologies, and processes, development distribution is grow- ing constantly. Development is shifting from single contractors to distributed projects, where teams are scattered across multiple companies, time zones, cultures, and continents. The global trend toward software outsourcing has led to software companies needing a reliable basis for making make-or-buy decisions or for verifying the development schedule and cost offered by contractors if they decide to buy parts of a software product. 1.3 Project Management and Estimation Are Key Success Factors 5 Software Development Is Still a Largely Human-Intensive Process. Moreover, software development is a human-based activity with extreme uncertainties from the outset. Robert Glass (2002) reiterated this fact by saying: “Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.” Software development depends on the capabilities of developers and on the capabilities of customers and other involved parties. Software Products Have an Abstract Character. Probably none of the afore- mentioned aspects has as large an impact on the difficulty of software production as does the abstract character of software products. It is this “softness” of software products that makes software engineering differ from other, “classical,” engineer- ing domains. To create software, developers start with customer requirements and go through a sequence of transformations during which all involved parties create, share, and revise a number of abstract models of various, usually increasing, complexity. In addition, individual project tasks in a transformation sequence are usually highly interdependent. The intangible and volatile character of software products—especially requirements—makes them difficult to measure and control. This contributes to software development being a mixture of engineering, science, and art. 1.3 Project Management and Estimation Are Key Success Factors Understanding the importance of accurate estimation, and a willingness to put in the resources... are vitally important to a company’s success. —Katherine Baxter The complex and multidependent character of software development makes man- aging software projects a challenging task. A software project should, like any other project, be considered in terms of a business case. It should therefore lay out the reason(s) for the investment, the expected benefits of the initiative, the costs to make it happen, an analysis of the risks, and the future options that are created. A software project also requires, as one of its key success factors, effective manage- ment. It must focus on areas critical for financial success, the effective use of resources, an analysis of market potential and opportunities for innovation, the development of a learning environment, and so on. 6 1 Challenges of Predictable Software Development Criteria of Project Success The classical definition of “project success” is “a project that provides software of required functionality and quality within cost and schedule.” Except for the meaning of “quality,” which has been a subject of discussions for years, it is perhaps a clear definition of project success. But is it really? In practice, success has a number of faces. Although perhaps not deemed “a success,” a project that has not met some of the classical success criteria can still be far from a complete disaster. For example, if the project is canceled in a timely manner because it cannot meet the functionality and quality requirements within a reasonable budget and time, it could be classi- fied as not having failed—under the condition that lessons learned can be applied in future projects to avoid a similar situation. Software project management is a key project success factor, and, as aptly noted by Barry Boehm, “Poor management can increase software costs more rapidly than any other factor.” A number of bad management practices may lead to failed projects, and one of the most common aspects of poor project management, which typically results in a project crisis, is poor effort estimation. Glass (2002) points to poor effort estimation as one of the two most common causes of runaway projects, besides unstable requirements. Rosencrance (2007), in her survey of more than 1,000 IT professionals, reports that two out of the three most important causes of an IT project failure are perceived to be related to poor effort estimation, in particular insufficient resource planning and unrealistic project deadlines. Effective project management requires reliable effort and schedule estimation support. On the one hand, project managers need a reliable basis for developing realistic project effort, schedule, and cost plans. On the other hand, as project management is to a large extent a political game, they need a reliable and convin- cing basis for negotiating project conditions with project owners and/or customers. In the latter scenario, simple, gut-feeling estimates are definitely insufficient to justify realistic project plans against demands and expectations of other project stakeholders. Yet, independent of these findings, many software organizations still propose unrealistic software costs, work within tight schedules, and finish their projects behind schedule and budget, or do not complete them at all. 1.4 What is a “Good Estimate”? A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets. —Steve McConnell Further Reading 7 The basic question of software effort estimation is “What is a good estimate?” Traditionally, effort estimation has been used for planning and tracking overall resources, such as staff required for completing a project. With this objective in mind, over the years, researchers have been pursuing an elusive target of getting 100 % accurate estimates in terms of the exact number of person-hours required to complete on a software project. Effort estimation methods that grew up on this goal focus on providing exact point estimates. Yet, software practitioners nowadays require from effort estimation compre- hensive decision support for a number of project management activities. They noticed that even the most accurate estimates are worthless if they cannot be reasonably justified to a project sponsor and customers or if they do not provide guidelines on what to do if the project is not going to meet estimates. From this perspective, one of the critical characteristics of good estimates is the additional information provided to support project decision making. Firstly, project decision makers need to identify the project areas that are responsible for increased devel- opment effort in order to have a transparent and convincing basis for renegotiating project resources and/or scope with the project sponsor. As aptly concluded by Tom Demarco (1982), the purpose of estimation “is not to solve any of the problems of actually getting a system built, but rather to make sure you encounter the fewest number of surprises as you undertake this work.” Secondly, they need an indication of the effort-related development processes that can potentially be affected in order to improve productivity at low overhead—“low-hanging fruits.” Summarizing, a good estimate is one that supports the project manager to achieve successful project management and successful project completion. Thus, a good estimation method is one that provides such support without violating other project objectives such as project management overhead. Tip " A good estimate is one that supports project management activities such as planning and negotiation of project resources, managing changes and risks, etc. A good estimation method should thus provide—in addition to single point estimates—transparent information on project-related factors affecting develop- ment effort. Further Reading R. Charette (2005), “Why software fails [software failure],” IEEE Spectrum, vol. 42, no. 9, pp. 42–49. This article looks at the status and the future of software. In the context of trends in size and complexity, it gives an overview of famous software disasters and their reasons. Among the most relevant causes of failed software projects are unrealistic or unarticulated project goals, inaccurate estimates of needed resources, and inability to handle the project’s complexity. 8 1 Challenges of Predictable Software Development L.J. Osterweil (2007), “A Future for Software Engineering?,” Proceedings of the 29th International Conference on Software Engineering, Workshop on the Future of Software Engineering, Minneapolis, MN, USA: IEEE Computer Society, pp. 1–11. This article identifies common trends and key challenges of software engi- neering practice and research. Among other items, it asks about the future of design, modeling, and quantitative quality control of something as intangible as software. Y. Wang (2007a), Software Engineering Foundations: A Software Science Perspective, CRC Software Engineering Series, vol. 2, AUERBACH/CRC Press. In Sect. 1.3 of his book, the author discusses general constraints of software and software engineering. He distinguishes three interrelated groups of constraints: cognitive, organizational, and resources constraints. For each group, the author lists and specifies in detail several basic constraints. E. Yourdon (2003), Death March, 2nd Edition, Prentice Hall. This book is one of the software engineering and project management classics, which, although not being technologically completely up-to-date now, discusses timeless traps of software project management. The author discusses reasons for software projects being what it calls “death march” projects; that is, projects that are sentenced to fail from the very beginning because of their unrealistic set up. Typical symptoms of a “death march” project are: (1) schedule, budget, and staff are about half of what would be necessary, (2) planned product scope is unrealistic, and (3) people are working 14 h a day, 6 or 7 days a week. Author suggests a number of useful solutions to avoid and, if this is not an option, to rescue death march projects. S. McConnell (1997), Software Project Survival Guide, 1st Edition, Microsoft Press. The book provides a set of guidelines on how to successfully perform software projects. For each major stage of software development, the author refers to the most common weaknesses that software projects typically face and discusses ways of addressing them in order to successfully get through the project. T. DeMarco and T. Lister (1999), Peopleware: Productive Projects and Teams, 2nd Edition, Dorset House Publishing Company, Inc., p. 245. This book discusses human aspects of software engineering. Authors show that the primary issues of software development are human, not technical. F. P. Brooks (1995), The Mythical Man-Month: Essays on Software Engineer- ing, Anniversary Edition, 2nd Edition, Addison-Wesley Professional. This book discusses human aspects of software engineering. Fred Brooks makes a simple conjecture that an intellectual job, such as software Further Reading 9 development, is completely different from physical labor jobs, such as tradi- tional manufacturing—although both jobs may be human-intensive. Using this assumption, the author discusses in a number of short essays people- and team- related aspects of software development projects. The book discusses many important issues of managing human resources, such as work environment, team building, and organizational learning. Finally, the author outlines impor- tant pitfalls of managing software projects and development teams and suggests a number of interesting solutions to these pitfalls. J. E. Tomayko and O. Hazzan (2004), Human Aspects of Software Development, Charles River Media Inc., p.338. The authors devote their book to software engineering as a human-intensive activity. They discuss a number of social and cognitive aspects of software engineering such as teamwork, customer–developer relationships, and learning processes in software development. T. DeMarco (1982), Controlling Software Projects: Management, Measure- ment, and Estimates, Prentice Hall. This book is another software engineering and project management classic. It discusses timeless aspects of managing software projects on the basis of quanti- tative information. The author devotes three out of four parts to project estima- tion and measurement. The first part of the book addresses the issue of project estimation as a key element of project control. The author discusses the typical challenges of estimation and shows examples of how to implement successful estimation processes within a software organization. Project Management Institute, Inc. (2013), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th Edition. The PMBOK provides a collection of best practices on professional project management. The body of knowledge presented in the book includes well- recognized and widely applied project management processes and associated techniques. Among other project management processes, the PMBOK provides standard procedures and guidelines regarding project estimation. Moreover, relationships of estimation to other project management processes are well illustrated and comprehensively explained. S. Berkun (2008), Making Things Happen: Mastering Project Management, Revised Edition, O’Reilly Media. This book is a collection of essays, each of which addresses selected aspects of project management. The essays are organized around three major project aspects: plans, skills, and management. For each, it discusses key success criteria, associated challenges, and best-practice solutions. Moreover, he illustrates issues with a number of real-life examples. 10 1 Challenges of Predictable Software Development M. Lopp (2012), Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, 2nd Edition, Apress. The book comprises a number of essays devoted to the subject of managing humans and work activities in software development projects. He discusses typical behaviors of managers and engineers, and typical problems of interactions between these two groups of project members. The author specifies, in a very expressive manner, the skills a manager should possess to deal with these issues in everyday life. For each challenge, the author sketches an example situation and suggests best-practice solutions. S. McConnell (2006), Software Estimation: Demystifying the Black Art, Microsoft Press. In the first chapter of his book, McConnell presents his view on what constitutes a “good estimate.” He starts with two basic aspects: (1) distinguishing between estimates, plans, and bids and (2) accounting for estimation uncertainty and considering estimates in probabilistic terms. Next, he takes a critical look at the common definitions of good estimates dominated by estimation accuracy perspective. Principles of Effort and Cost Estimation 2 Plans are nothing; planning is everything. —Dwight D. Eisenhower (quoting 19th-century Prussian General Helmuth von Moltke) One of the reasons for failed estimates is an insufficient background of estimators in the area of software estimation. Arbitrary selection and the blind usage of esti- mation methods and tools often lead to disappointing outcomes, while the under- lying reasons remain unclear. In discussions with corporate management, it is not uncommon to hear the phrase “think of a number and multiply by three.” Deliberate decisions regarding the particular estimation method and its knowledgeable use require insight into the principles of effort estimation. In this chapter, we introduce the basic methodological concepts of software effort estimation. We introduce basic terminology and characterize typical estima- tion stakeholders. Next, we describe the typical context of software effort estima- tion and associated aspects of optimizing software project scope and resources. Further, we summarize typical purposes of effort estimation met in practice, and we sketch a basic estimation process including its primary inputs and outputs. Finally, we overview the project estimation life cycle and illustrate components of project effort estimation. 2.1 Basic Concepts of Effort Estimation An estimate is the most optimistic prediction that has a non-zero probability of coming true. Accepting this definition leads irrevocably toward a method called what’s-the-earliest-date- by-which-you-can’t-prove-you-won’t-be-finished estimating. What’s a better definition for “estimate”? An estimate is a prediction that is equally likely to be above and below the actual result. —Tom DeMarco A. Trendowicz and R. Jeffery, Software Project Effort Estimation, 11 DOI 10.1007/978-3-319-03629-8_2, # Springer International Publishing Switzerland 2014 12 2 Principles of Effort and Cost Estimation 2.1.1 Basic Terminology Software effort estimation is often confused with project planning and bidding. These processes, although related to one another through overlapping activities, differ with respect to their objectives and the outputs they are supposed to deliver. Tip " Do not commit to estimates as internal project targets and do not provide them to customers as bids. Use estimates as a basis for creating internal project targets; that is, realistic estimates, increased by contingency reserves needed for dealing with anticipated project risks. Use targets as a basis for bidding processes. Estimate Project Management Institute (2013) defines the estimation objective as providing an approximation (estimate) of the amount of the resources needed to complete project activities and to deliver outputs—products or services—of specified func- tional and nonfunctional characteristics. Traditionally, an estimate is considered in deterministic terms, that is, as a single value. In order to account for inherent estimation uncertainty, range estimates are alternatively proposed. Instead of a single effort value, estimates are represented by a range and/or distribution of possible effort values. In order to account for esti- mation uncertainty, known project risks, such as little domain experience of the development team, are taken into account. Point estimates often implicitly incorpo- rate acceptable project risk as they are derived from range estimates through discretization. Traditionally, an estimate is considered in deterministic terms, that is, as a single value. But as DeMarco suggests, using an estimate that represents “the most optimistic prediction that has a non-zero probability of coming true” may, in practice, have fatal consequences. Uncritically selecting the most optimistic prediction may easily result in running a software project into high risk of over- running initial estimates. In the light of practical experiences, estimates should rather be defined as the predictions with highest probability of becoming true instead of the most optimistic ones. In the case of projects that are considered very risky, estimates should even be “biased” toward pessimistic predictions that have nonzero probability of coming true. For example, PMI (2103) recommends explicit inclusion of contingency and management reserves in order to account for known and unknown risks, respectively. In order to account for inherent estimation uncertainty, range estimates are alternatively proposed. Instead of a single effort value, estimates are represented by a range and/or distribution of possible effort values. 2.1 Basic Concepts of Effort Estimation 13 Tip " Estimates should always be represented as a range of possible values. If a point estimate is required, it should represent the prediction that has the highest probability of coming true. Scope In project management (PMI 2013), scope may refer to Product scope: the features and functions that characterize the product, service, or result and/or Project scope: the work that needs to be accomplished to deliver the product, service, or result with the specified features and functions. In software engineering, adjusting project scope in response to scarce project resources typically refers to reducing the product scope by cutting the functionality of a delivered software product. In consequence, the project scope is automatically reduced by the activities needed to deliver the excluded functionality. The project scope can also be indirectly reduced through reducing software quality in that specific quality assurance activities are not performed; this saves required project resources but decreases the quality of resulting software products. Target The objective of internal project planning is to set up a target for the resources needed to complete project activities. Such a target is also commonly referred to as project budget—although it does not refer to money but to effort. Project target represents an internal commitment and consists of estimated resources increased by so-called contingency reserves1 (PMI 2013). These reserves are resources, such as effort, that are used at the discretion of the project manager to deal with anticipated but not certain events—“known unknowns.” Contingency reserves typically cover rare events that are not included in the project plan or its work breakdown structure because under usual project conditions, they are very unlikely to occur. Examples of such events are loss of critical project staff or collapse of subcontractor’s business. A realistic project plan should always have room in it for unforeseen events. Project managers should anticipate possible risks, evaluate their 1 Note that in addition to contingency reserves for addressing impacts of anticipated project risks, PMI (2013) recommends planning management reserves to cover unforeseen risks and changes to the project. Both contingency and management reserve are included in the target. 14 2 Principles of Effort and Cost Estimation impact on effort, and adjust project plans appropriately. Yet, they should take care not to double-count risks by considering them in both estimation and project planning. During estimation, project managers should consider the uncertainty of estimated values or the impact that known environmental factors may have on effort. Estimates of resources will be available to a project manager during the project, independent of anticipated project risks. During project planning, on the other hand, project managers assign each identified risk with specific resources (contingency reserves) needed for dealing with risks in case they occur. Contin- gency reserves may then be utilized only if the risk to which they are assigned occurs. Tip " When preparing estimates and project targets, remember not to double-count the same risks. Consider them either during estimation, by means of uncertainty, or during project planning, by means of contingency reserves. Identifying targets that have potentially been set up already for a project is one of the essential aspects of project estimation. When asked for estimates, we should first establish whether any project targets have already been defined—for example, based on the customer’s preferences. If this is the case, “estimation” may in fact mean figuring out how to fit the project to the target—especially when, for a given project scope, the target imposed upon the project is smaller than any realistic estimate. Tip " When you are asked to provide an estimate, make sure you are aware of any target already specified—especially when the target is smaller than any reasonable estimate for a given project scope. In such a case, “estimating” will actually mean determining how to meet the target. In practice, targets—if actually predefined—and estimates should be aligned in an iterative process, with both being subject to potential adjustments. Adjusting estimates does not mean manipulating them to fit targets—particularly if they are unrealistic. It means adjusting project-related factors affecting effort. In the first instance, project characteristics such as team capabilities or tool support should be optimized—to the extent feasible—in order to improve development productivity and thus reduce effort. If adjusting the project characteristics does not bring the expected effect, then modifying the project scope, that is, the functionality and quality of the project’s work products, may be necessary. Each time we adjust the project scope, we need to repeat the estimation in order to prove that we are still aligned with the project target. But adjusting a project is not always possible, particularly when the project scope is also fixed by a customer and is not subject to negotiation. In such cases, the targets must be adjusted; otherwise, we face what Yourdon (2003) calls a death march project: a project that is destined to fail, with 2.1 Basic Concepts of Effort Estimation 15 the probability being proportional to the discrepancy between targets and realistic estimates. In one large financial organization where we worked, there was a business manager who regularly set the target for developers at half their calculated point estimate with the words “take it as a challenge.” Tip " If there are predefined targets, perform estimation as an iterative process in which targets and estimates are aligned by negotiating other components of the project. For a fixed project target, try negotiating the project scope. Alternatively, the project’s environment characteristics that have an impact on development pro- ductivity may be adjusted appropriately in order to meet the target. Bid The objective of bidding is to agree on the project resources with external contractors of a software product or service. Bids typically rest on a point value and refer to the software product price and project duration offered externally. Tip " Typically, we don’t need an accurate estimate; we need an accurate commitment (Armour 2008). Yet, it is always worth trying to be fair and propose to customers a range of bids that reflect the inherent project’s uncertainty. If a customer is not willing to accept such “imprecise” range bids, then you still can give a “precise” one taken from a range that accounts for project risks and profits. Bids include the internal target and profit, where profit might also be considered in nonfinancial terms. Kitchenham et al. (2003, 2005) note, for example, that in a competitive situation, the lowest compliant bid typically wins the contract. In consequence, knowledge of the extent and capability of competitors usually affects—at least to some extent—the pricing decision represented by the bid. A company may, for example, decide to take on a project below the planned cost in order to win a contract and expand its market share by gaining a new customer. Work Plan vs. Commitment Plan Armour (2005) points out that the difference between internal and external commitments is so important that it should be natural to prepare two project plans, one each for internal and external commitment. He calls them work plan and commitment plan, respectively. Work plan reflects the resources the project will need according to internal estimates and targets, based on incomplete knowledge of the project and risks (continued) 16 2 Principles of Effort and Cost Estimation Work Plan vs. Commitment Plan (continued) anticipated at the time the work plan is created. This corresponds to what is traditionally understood under the project plan and is what the project team works with. For example, a work plan includes uncertainty about the skill level of the team or the potential risk of losing critical team members during the project. Such internal issues are typically not presented to the customer. Commitment plan is the plan presented to the customer. It incorporates the work plan plus a contingency buffer to account for uncertainty at the time of creating the commitment plan. This uncertainty may have a number of different sources: On the one hand, incomplete knowledge of the project environment; on the other hand, known and unknown risks accounted for through contingency and management reserves (PMI 2013). As pointed out by Armour (2008), in practice, it may not really matter if we can provide an accurate point estimate. What matters is that we can provide an accurate commitment. In other words, it is important that we can commit ourselves to a certain amount of resources and that we are aware of the risk of exceeding these resources. From this perspective, commitment is the point on the estimate probability distribution curve which we promise to the customer. Summarizing, a bid represents a combination of three elements: estimated cost, contingency margin, and profit. It represents an external commitment, that is, a commitment to an external project stakeholder, such as a contractor. Tip " Commitments are negotiable. Estimates are not negotiable. If a fixed bid or target is less than the estimate, then other project constraints such as functionality and quality should be adjusted. Actual Actual is the true value of the project resources that are actually needed to successfully complete project activities. Actual resources are known after project completion. Estimates vs. Target vs. Bid The practical consequences of confusing estimates, targets, and bids are unrealistic internal and external project commitments, which lead to failed projects. One of the common sources of such a situation is a lack of estimation/planning competencies and conflicts of interest between project stakeholders. 2.1 Basic Concepts of Effort Estimation 17 For example, typical software developers tend to be relatively young and, although having software project competence, they do not have much decisive power. On the other hand, although lacking software project knowledge, sales personnel or business managers tend to have more decisive power than developers. In consequence, developers fit their estimates to—often unrealistic—expectations of a sales department or business manager. Although in this book we focus on estimates, keep the aforementioned differences in mind in order to avoid confusion when estimating and when using estimates for creating project budgets and bids. Tip " Do not allow a sales department to provide estimates for software projects instead of developers. 2.1.2 Effort Estimation Stakeholders As for any project activity, there are a number of individuals that have interests in effort estimation. We distinguish several roles associated with effort estimation, depending on their stakes and exact involvement: Estimation Process Owner: This role is responsible for introducing and maintaining estimation processes, methods, models, and data within an organi- zation. This person has in-depth knowledge of the estimation method and manages estimation initiatives and activities within the organization. The esti- mation process owner is typically a dedicated full-time position within an organization. Estimator: This role uses estimation methods and models existing within an organization for estimating particular development projects. A project manager, who estimates and manages projects, typically plays the role of the estimator. Domain expert: This role provides input information for building an estimation model when measurement data are missing or insufficient. Domain experts should be knowledgeable in project effort dependencies within the context for which the effort estimation method is applied. Domain experts do not have to be knowledgeable in effort estimation. They should have a basic understanding of estimation and know which factors and to what extent they influence effort in the project, within this context. In the case of estimation based on human judgment, however, domain experts play the role of estimators and thus should be addi- tionally knowledgeable in project effort estimation. Decision maker: This role represents other project stakeholders who are not directly involved in the estimation process but who have the power to affect the project, including the performance of estimation. For example, a project owner (also referred to as a project sponsor) may place pressure on estimators with respect to project resources and thus bias estimates. An example of this situation from practice might be a Scrum planning meeting (Rubin 2012) during which a 18 2 Principles of Effort and Cost Estimation powerful product owner biases estimates of the Scrum team. In the extreme case, it is enough that the product owner raises an eyebrow or shakes his/her head and the Scrum team then bias their estimates in order to please the product owner. In reality, the role of the estimation process owner and the estimator is often played by the same person who is then responsible for both effort modeling and estimation. 2.2 Effort Estimation in Context Early in the project you can have firm cost and schedule targets or a firm feature set, but not both. —Steve McConnell 2.2.1 Project Equilibrium Triangles A typical question that software project managers need to answer is how to provide a product of required functionality and acceptable quality with limited resources? In Fig. 2.1, this project management dilemma is illustrated by means of two so-called project equilibrium triangles. The project scope triangle represents a trade-off between project outputs and inputs. The three competing objectives are: software functionality, software quality, and resources needed to accomplish the former two. The resources triangle represents a trade-off between project resources, namely, staffing, duration, and effort. For example, if the customer requires project completion within a fixed effort and/or duration, then the overall project equilibrium can be accomplished through affecting other dimensions, that is, staffing within the resources triangle and/or functionality and quality within the scope triangle. A key to project success is to achieve equilibrium in both scope and resource triangles. The element that connects the project scope and resources is productivity, traditionally defined as a ratio of project outputs to its inputs. One practical consequence is that depending on productivity, the same project scope may require different amounts and abilities of resources, and vice versa, the same amount of resources may deliver different amounts of functionality and quality. The exact trade-offs within and between project scope and resource triangles depend on the particular project context, which consists of multiple environmental characteristics, called context factors. Example context factors are capabilities of involved personnel or technologies employed (for a detailed discussion of context factors, refer to Sect. 3.1). 2.2 Effort Estimation in Context 19 Project Staffing, Duration, Time, and Budget Staffing refers to the number of persons required to complete a certain project work, task, or activity. The unit of staffing is the number of persons. As we discuss in the subsequent paragraphs of this chapter, the magnitude of staffing is closely related to, and depends on, the time and effort planned for the work. Duration refers to the total elapsed time needed to complete a particular work, including nonproductive time such as breaks, holidays, and sick leave. Typical units for project duration are hours, days, months, or years. For example, one person may need 5 days to complete a task that requires 5 h of fully productive work, because the person can work on the task for only 1 h per day. Effort is a combination of person and time. It refers to the amount of fully productive work time one person would need to complete a certain work. If multiple persons work on the same task, each for different amounts of fully productive time, then the total work effort is computed by summing the working time for all persons. Typical units of work effort are person-hours, person-days, person-months, and—for large projects—person-years. For example, if completing a certain work task requires three persons working on it for 5 h each, then the total work effort for this task will be three persons multiplied by 5 h of productive work per person, which equals 15 person-hours of effort. In practice, time is often confused with duration (elapsed time). In consequence, task duration is often estimated as a direct derivative of the estimated effort, which is required for completing the task. This would be correct under the assumption that all task activities were performed one after another, without breaks, by equally performing personnel. Project management practice teaches that project duration is a derivative of a task’s effort and staffing with consideration of dependencies between task activities, availability and performance of personnel assigned to tasks, project scheduling, and addi- tional internal and external project constraints. Since effort, persons, time, and duration are interrelated, in practice, planning project duration is an iterative process that starts from initial effort estimates and continues with scheduling work tasks, assigning resources, and computing task duration. If the perfor- mance of the assigned human resources differs from that assumed initially, or the resulting task duration is not acceptable, then the initial effort estimate needs to be revised, and the planning cycle must be repeated. Budget refers to the amount of money available for project realization. Besides this monetary meaning, the term budget is also used to refer to the project target, that is, to the total amount of effort needed to complete project activities. 20 2 Principles of Effort and Cost Estimation Specified Quality Context Customers Effort Optimize Unknown Developers Scope Productivity Optimize Functionality Resources Specified Customers Staffing Duration Fig. 2.1 Project equilibrium triangles Tip " “Projects must meet the needs of customers and users in order to be successful. It is possible to meet budget and time goals but still be unsuccessful if customer needs have not been met.” [Anonymous] In industrial practice, two project optimization situations typically take place. Figure 2.1 may illustrate a so-called fixed-scope project, in which the contractor specifies—at a more or less fixed level—functionality and quality the software project should deliver. Project resources are then estimated to meet the project scope objectives defined by the contractor. In a fixed-budget project, on the other hand, the contractor specifies one or more project resources—typically project duration or cost, or both. In this case, the project scope—functionality and quality— needs to be optimized to meet the fixed resource requirements. In fixed-scope projects, if the contractor does not specify any particular requirements concerning the level of effort, staffing, and duration, the provider may decide about specific trade-offs between these three aspects of software project resources (as represented by the small triangle in Fig. 2.1). Typically, a provider estimates project effort first and then, based on the available human resources (staffing), determines a reason- able project duration. In fixed-budget projects, where the contractor determines the cost and/or duration of the project, the basic strategy of the provider is to optimize project scope (functionality and quality) in order to fit predefined resources (large triangle in Fig. 2.1). Yet, a provider may additionally optimize the detailed project resources (small triangle in Fig. 2.1). The scope of possible optimization between effort, staffing, and duration depends to a large extent on (1) whether a contractor fixes only one or both cost and duration aspects and (2) whether cost has been expressed in monetary terms or effort. If only one aspect, duration or cost, is fixed, the other can be adjusted by appropriately adjusting staffing level on the project. If fixed cost is expressed in monetary terms, then a provider has the additional 2.2 Effort Estimation in Context 21 possibility of adjusting project effort (i.e., variable cost) by manipulating the fixed cost of the project, for instance, infrastructure costs. In some cases, typically public projects, a contractor fixes cost in terms of effort. In this situation, the provider has less room for optimization within the small triangle (Fig. 2.1). Tip " Before starting estimation, determine first if you are expected to estimate project resources for a fixed project scope (product’s functionality & quality) or to estimate the feasible project scope to fit fixed (target) project resources. Release planning is an example of optimizing the project scope to fixed resources in the context of incremental or multirelease software development. The goal of release planning is to optimally distribute product functionalities—at required quality—throughout a sequence of development projects of limited size in terms of effort or duration. Priorities assigned by a contractor to individual software functionalities and interdependencies between functionalities are additional constraints to release planning. Each project is optimized by maximizing benefit in terms of the product’s functionality and quality within acceptable cost—effort or duration. 2.2.2 Optimizing Project Resources Triangle As John Boddie noticed, “Everybody wants things good, wants them fast, and wants them cheap. Everyone knows you can actually achieve any two of the three.” Software engineering is not different. People expect software of high quality, available quickly, and at low budget. The resources equilibrium triangle in Fig. 2.1 represents the inherent association between project effort, staffing, and duration. Based on multiple industrial experiences, the relationship between soft- ware development effort, staffing, and duration forms a bell-shaped curve. Particu- lar functional forms used for modeling staffing distributions are represented by Rayleigh (Norden 1958; Putnam and Myers 2003), Gamma (Pillai and Nair 1997), or Parr’s (Parr 1980) curves. One of the practical consequences of the effort- staffing-duration relationship is that after fixing the functional and nonfunctional scope of a software product, one of the project resources may still be affected—at least to some extent—by manipulating other resources. For example, for a fixed project scope, we may adjust development effort by affecting project staffing level and/or its duration. Figure 2.2 illustrates example distributions of staffing across the software life cycle in two different types of projects. The solid curve represents a so-called build- quality-in type of project where major effort is spent in early development phases, such as requirements specification and design. The main purpose of focusing project effort in its early phases is to avoid rework during its later phases such as 22 2 Principles of Effort and Cost Estimation Raiyleigh curve („Built-Quality-In“ type of project) Peak staffing Gamma curve („Test-Quality-In“ type of project) Staffing Level Parr’s curve (Small, Follow-up project) Life Cycle Phase 39% of total effort Development Maintenance Life Cycle Time Fig. 2.2 Distribution of software life cycle staffing verification, validation, and maintenance. Observations from practice show that defect prevention is much less expensive than rework. Moreover, the longer the time span between injecting a defect and reworking it, the more effort it takes to correct (Boehm and Basili 2001). For example, it is observed that finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase. The dashed curve is a test- quality-in type of project, in which little effort is spent on early development phases, which typically results in major rework overhead during later project phases such as verification, validation, and early maintenance. Finally, the dash-dotted line represents projects for which some staff are already working at the beginning of the project. One such case would be a follow-up project where some work has already begun in the previous project. How to Interpret the Staffing Curve? The staffing curves represent time- sensitive effort models, that is, effort models that represent the effect of trading off project staffing against project time and effort You may agree with particular shapes of the staffing curves or consider them as mathematically and practically bizarre. Yet, you need to remember that they only represent empirical observations that authors have made in particular contexts and tried to approximate with mathe- matical equations. But these curves do not necessarily correspond to your specific project environment. Thus, as with any other fixed-model approach to effort esti- mation, staffing curves should not be reused uncritically, without adapting them to the particular context. They can and should, however, be considered as representing universally true consequences of staffing-time-effort trade-offs. The Rayleigh and Parr’s curves represent multiple observations from practice. They suggest that investments in software quality assurance practices in the early stages of a software development process contribute to increased overall project performance, that is, efficiency and effectiveness of development activities (e.g., Wang et al. 2008). 2.2 Effort Estimation in Context 23 Tip " One of the essential practical consequences of the effort-staffing-time dependency is that without the appropriate resources available on time, the project is actually doomed to fail. Time-Effort Trade-Offs Independent of the assumed functional form of the project staffing distribution, effort, time, and staffing levels always stay in a close dependency with each other. In other words, you cannot manipulate one of these parameters without affecting others—an eye must always be kept on the trade-off between these three. One practical consequence of this observation is that there is no single pair of effort- time values for developing a software product of a given functionality and quality within an organization with certain productivity of the development process. In other words, we may choose from among multiple options of effort-duration pairs, which create a curve of the project effort-time trade-offs. Yet, although we may expect so, the curve does not represent a straight line, but is nonlinear. This also means that the effort area under the staffing curve in Fig. 2.2 does not remain constant, although it may seem so at first glance. In practice, effort may increase as the time is compressed through putting more staff into the project. This loss in process productivity is caused by a factor Ross (2008) calls management stress. In essence, management stress comprises constraints on a software development process with respect to increasing levels of project staffing. In software development practice, several project characteristics are used to indicate management stress. The most common are size of the project measured in terms of size of its deliverables or size of the project team. All of these indicators are, however, proxies for the amount of project coordination and communication. The inevitable overhead associated with project coordination and communication is the main factor responsible for increasing effort as project staffing increases, for example, to shorten project schedule. Wang (2007a, b) expresses this effect formally in his law of work coordi- nation. In the research carried out by He Zhang (2008), it was shown that variation in staff assimilation rates on a project when new staff are added will either cause the project to finish later, finish earlier, or not impact the completion time. The critical factor is the rate at which staff can be successfully and productively assimilated. The solid line in Fig. 2.3 illustrates the management stress phenomenon by example using the functional form2 of the effort-schedule dependency observed by Putnam and Myers (2003) and Jensen (1983). We have extended these obser- vations (dotted line) by the hypothesized effects of extremely low project staffing. Minimum project time represents minimum development time achieved by putting maximal reasonable staffing into the project, that is, staffing that shortens 2 In practice, other functional forms of the effort-schedule dependency are possible. 24 2 Principles of Effort and Cost Estimation 1.6 Very large Practical Region (Reasonable team size) Impractical 1.4 team Region 1.2 Development Effort 1.0 Exponential Minimum Development Time increase of coordination 0.8 overhead 0.6 Multitasking overhead 0.4 Minimum team Impossible 0.2 Region 0.0 0.9 1.0 1.1 1.2 1.3 1.4 Development Time Empirical observations of Putnam (1980) and Jensen (1983) Hypothetical curve for extremelly low project staffing Fig. 2.3 Effort-time trade-off for a given project size and process productivity project time with an acceptable increase in the project effort overhead needed to coordinate work. Project coordination comprises such aspects as team communi- cation or simultaneous work on multiple project tasks. Impractical region represents the situation where project staffing is reduced beyond a minimal reasonable level, such as one person per independent work item. Periods of effective work in the project in this case will be much shorter compared to time spent outside the project. The time required for switching back to the project is in this case relatively large compared to the very short duration of effective project work. In consequence, the large overhead for multitasking will again be disproportional to potential gains in project duration. Moreover, reducing the project team may require that one person is assigned to multiple work items, some s/he has little experience with. This would cause further productivity loss and increase of overall project effort. Impossible region represents the situation where increasing project staffing— team size—entails an increase in project coordination overhead that is dispropor- tional to gains in project duration. In other words, reduction in project time does not compensate for an enormous increase in project effort overhead. A critical conse- quence of this observation is that one cannot compress estimated, reasonable schedules indefinitely by simply putting additional resources into the project without increasing development effort. 2.2 Effort Estimation in Context 25 Tip " Never shorten a schedule estimate without considering the resulting possible increase in effort. For example, if 10 developers can create a software product within 10 months, can 100 developers deliver the same product within 1 month, or can 2,000 developers do it within 1 day? Probably not, and there are several reasons why it is impossible in practice. For example, Larger teams require more overhead for work coordination and management. Larger teams increase complexity of communication paths, which not only require more communication overhead but also increase the chance of miscommunication. Shorter project durations require more work to be done in parallel, which is not always possible and increases the chance that some products are based on incomplete or erroneous components—thus increasing the amount of rework. The negative effect of increasing a team in order to shorten the project schedule is even more severe if we add people during the project runtime, especially when the project is already late. Such attempts to rescue late projects may in practice have a totally opposite effect. Brooks (1995) addresses this phenomenon in a law (so-called Brook’s Law), which says that adding new personnel to a late project makes it even later. In this case, we need to consider the extra overhead for introducing new staff into the already running project—in addition to the overhead on communication and coordinating parallel tasks within a larger team. When introducing new staff into the project, project performance suffers in two ways: (1) team members need a certain effort to introduce new staff into project activities and (2) team members who introduce new staff cannot work on the project activities at that time. As mentioned above, the effect will depend on the staff assimilation rate. Summarizing, there are several practical implications of the effort-time trade- off. First, there is an impractical effort-time region representing an extremely slow project. An extremely stretched schedule does not make economic sense in practice because the delivery time is too long to be accepted by a customer, compared to possible cost savings. Moreover, there is an impossible effort-time region representing an extremely fast project. Tip " In practice, planning to operate with a smaller development team over a longer project schedule gives better results in terms of product quality than planning a larger team over a shorter schedule. Wang (2007a, b) formally formulated empirical observations of the time-effort- staffing trade-offs in his laws of work coordination, which we summarize briefly in Table 2.1. For a detailed discussion of the laws and rationale behind them, refer to Wang (2007a, Sect. 8.5) or Wang (2007b). 26 2 Principles of Effort and Cost Estimation Table 2.1 Wang’s laws of work coordination Law Definition The law of coordinative effort in The actual effort of a coordinated project is a product of effort engineering needed to complete the work by one person (ideal effort) and the effort overhead needed for interpersonal coordination of the complete project team The coordination overhead is the product of the interpersonal coordination rate for individual team members and the number of pairwise coordination interactions among all team members Finally, the interpersonal coordination rate of an individual team member is an average ratio of the time the person spends on interpersonal coordination activities and the total working time of the person in a given project The law of incompressibility of In cooperative work, a given ideal project effort—that is, the effort effort one person would need to complete the project—cannot be compressed by any kind of staff allocation. This indicates that The duration of the project may be reduced via cooperative work of multiple personnel, but the total effort cannot be reduced below the minimum effort a person would require to complete the project The total effort in any type of cooperative staff allocation will be larger than the minimum effort The law of interchangeability of For a given effort, staffing and duration are transformable. This labor and time law indicates that the duration of a cooperative project is a function of staffing and the interpersonal cooperation rate for the given project Law of the shortest duration of There exists the shortest duration under the optimum allocation cooperative work of staff for a given ideal project effort with a certain interpersonal cooperation rate In general, there are a number of other ways to shorten project duration besides assigning additional staff to the project. Most, if not all of them, boil down to improving performance of an existing project team. Example means to achieve this include introducing additional tool support or improving software development or project management methods and processes. However, we need to keep in mind that every organizational change, even though it should contribute to long-term performance gains, requires investment, which typically results in a short-term performance drop. Effort-Time Trade-Off for Interdependent Work Tasks In project management practice, dealing with effort-time trade-offs is quite complex and involves more aspects than simply effort, duration, and staffing. In reality, software projects consist of multiple, mutually interrelated work tasks. In conse- quence, project duration is a function of individual task durations and their distribution—scheduling—within the whole project. 2.3 Objectives of Effort Estimation 27 Total project duration can thus be affected not only by manipulating the duration of individual work tasks but also by the way these tasks are distributed within the project. Yet, a number of nuances need to be considered before playing with project effort-time trade-offs. For example, we may want to affect project duration by changing the duration of individual work tasks. For this purpose, we manipulate staff assigned to selected work tasks, that is, we affect their duration at the expense of changed effort. Now, if these individual work tasks are not located on the project’s critical path, then the manipulations will likely not have any effect on total project duration—although it will affect the total project effort. Potential project resource manipulations—either on individual work tasks or on their distribution within the project—are limited by a number of project constraints. One of the most relevant constraints includes project internal and external restrictions on the sequence and timeline of project work tasks. External to the project, the sequence of work tasks or their exact point in time may be determined by customer-defined project deadlines or by the availability of external inputs or resources. Internal to the project, the sequence of work tasks is typically limited by the availability of intermediate project outcomes and the availability of shared project resources. Therefore, using a simple functional form curve for dealing with effort-time trade-offs within a project that consists of multiple interrelated tasks might lead to failed estimates. In such a case, the project manager needs to additionally consider a number of project aspects such as constraints on task scheduling. 2.3 Objectives of Effort Estimation Methods and means cannot be separated from the ultimate aim. —Emma Goldman Software effort estimation has been traditionally associated with simply planning the amount of resources required for completing project activities. Recently, how- ever, software practitioners require effort estimation to support them with a number of project decision-making tasks. It is a very important aspect of effort estimation that should be kept in mind when selecting an appropriate effort estimation approach. From a short-term perspective—a single project—effort estimation should pro- vide comprehensive decision support for managing project risks, whereas from a long-term perspective—multiple projects—it should guide process improvement initiatives aimed at increasing efficiency of work. Simultaneous to any newly arising estimation objectives, there is also continuous pressure to improve the cost- effectiveness of estimation itself. In practice, software decision-makers require estimation and planning not to take more than say about 5 % of the total project effort. In the next few paragraphs, we summarize briefly the most common objectives of effort estimation followed in the software industry. 28 2 Principles of Effort and Cost Estimation 2.3.1 Managing and Reducing Project Risks A common observation in the software industry is that project management decisions often fail because effort estimation methods do not provide sufficient insight into resource-related sources of project risks (Charette 2005, Jones 2006, Cerpa and Verner 2009). Project managers need to know not only, say, that a project is going to overrun an agreed budget—typically based on simple resource estimation—but they also require insight into potential causes of project overruns in order to timely and effectively mitigate the related project risks. For instance, studies performed by Jørgensen and Sjøberg (2001, 2004) as well as by Kitchenham et al. (2005) underlined the essential role of early and accurately identifying relevant factors influencing software development productivity and project effort—commonly referred to as effort drivers. It was observed that driven by irrelevant information, software managers tend to provide inaccurate estimates and fail to effectively justify and negotiate project cost and scope. When project target and bids are accepted based upon unrealistic estimates, they have a negative impact on the quality of project work—due to tight schedules and budget shortages. Effort estimation is thus required to provide transparent information on relevant effort drivers and their mutual relationships in order to support decision-makers in understanding what may go wrong, why it may go wrong, and what can be done to prevent it. A systematic estimation method should force project managers and the project team to critically review completeness and consistency of available project infor- mation. It is also required to bring together various project stakeholders, repre- senting different knowledge, perspectives, and interests, for the purpose of identifying information that would not probably be identified otherwise. Information considered during the estimation process should include such aspects as software functionality and quality, internal and external project constraints, and assumptions that need to be made implicitly because actual project knowledge is missing. It is important that there is a mutual connection between project estimation and risk management. On the one side, effort estimation should provide information on potential project risks. On the other side, it should use outcomes of other risk analysis activities as part of the input to project estimates. Since uncertain and incomplete information is an inherent source of risk in software project manage- ment, effort estimation is expected to handle it. In Sect. 4.4, we discuss in more detail handling estimation uncertainty. 2.3.2 Process Improvement and Organizational Learning Software development is characterized by human-intensive processes and rapid technological advances. This means that successful software projects, like in any other domain, require continuous process improvement and organizational learning. 2.3 Objectives of Effort Estimation 29 Industrial experiences gained by Jørgensen et al. (2002) and Jørgensen (2004a) show limited ability of software organizations to learn from estimation experience. Typically, the most probable effort is estimated at the project beginning and compared against the actual effort at the project end. If the estimated most likely effort deviates from the actual one, software practitioners usually do not learn more than that they were wrong. From this perspective, information on effort-related risks provided as output of effort estimation across multiple projects forms a basis for determining critical process deficiencies and learning from experience. For example, a recurrent negative influence of poor team qualifications on increased development effort may be an indicator of poor team selection and/or team training processes. Yet, comparing risks identified in different projects requires that they can be compared. In order to ensure comparability across projects, we must consider explicitly their environment. It is thus particularly important that a poten- tial effort estimation approach not only provides information on relevant effort drivers but also explicitly considers critical characteristics of a project context. Finally, when talking about learning and improvement, we must remember that effort estimation itself is a part of organizational processes and, as such, is subject to learning and improvement. Therefore, an estimation method should support improving the overall estimation process and the method itself, for instance, by identifying the causes of poor estimates. 2.3.3 Baselining and Benchmarking Productivity In industrial practice, software decision-makers often require a reliable basis for managing development productivity. Example productivity management activities include establishing productivity baselines, identifying productivity improvement potentials, or comparing a project’s productivity against baselines or against other projects. Improving productivity is a critical aspect of successful software projects, not only because it implies reduction in project effort, but also because of its indirect impact on the quality of delivered software products. As shown in the most recent industrial survey of Emam and Koru (2008), between 24 % and 34 % of software projects are considered unsuccessful—10–12 % canceled—due to low performance. On the other hand, benchmarking of software projects between different organizations is gaining increasing attention in the context of rapidly growing global development. Comparing a project’s performance in the context of software within outsourcing—near- or far-shoring—supports make-or-buy decisions and facilitates choosing between potential software suppliers. A typical situation in the software engineering domain is the existence of large discrepancies between project contexts—domain, technology, team capabilities, and so on—which results in large variations in development productivity across projects. One of the most critical practical consequences of this fact is that simple software productivity metrics based solely on software size and project effort are hardly comparable. In order to compare productivity, a number of factors influencing productivity must be considered. 30 2 Principles of Effort and Cost Estimation As productivity is closely related to software development effort (as illustrated in Sect. 2.5, Fig. 2.5), factors influencing productivity are at the same time factors influencing development effort. Effective management of both development effort and productivity requires considering these factors in an explicit and understandable manner. For example, when benchmarking software projects, we must ensure that we do not compare apples and oranges and that we consider as many factors as possible, which may potentially contribute to the observed produc- tivity discrepancies. In other words, we must ensure that the rationale behind the observed discrepancies is clear. In that sense, effort modeling can potentially support the baselining of productivity, which we can then use for the purpose of benchmarking software projects. 2.3.4 Negotiating Project Resources and Scope Poor communication among customers, developers, and users during the project bidding phase and during project realization is one of the major sources of troubled and failed software projects. Jørgensen (2004a), for instance, observed that experi- enced project managers always require justification of cost estimates so that they can be reviewed. Salas (2004) observed that estimates in the context of government/ military software acquisition were lacking clear and detailed justification. Moløkken et al. (2004) in their industrial survey observed that besides previous experience with an estimation method, its ability to support justification of project cost was a significant argument to select a certain estimation method. They observed that the proper support for communicating and justifying development costs is a particularly critical success factor in the case of external (outsourced) software projects. In consequence, price-to-win estimation strategies, demands to cut project costs, as well as political interests lead to unrealistic project schedules and budgets. Yet, effort estimation methods commonly used in the software industry do not support sufficient insight into cost-related factors that would provide a detailed and precise explanation of project estimates. In consequence, software project managers lack sufficient and reliable information for communicating software costs to customers and managers. 2.3.5 Managing Project Changes Agile software development has recently gained much industrial attention as an alternative to traditional “heavyweight” development processes. Consequently, increased flexibility is expected from the effort estimation process in order to support in software projects organized upon iterative and agile development pro- cesses, such as implemented in Scrum (Rubin 2012). This requires, for example, continuous accommodation by an estimation model to the changes in the set of 2.4 Estimation Life Cycle 31 predictive variables and in their relative impact on effort in each development iteration. In addition, there is a need for systematic feedback from the estimation process across development iterations in order to learn about the reasons for potential discrepancies between estimates and effort actually spent in a project. Finally, as one of the primary reasons for failed software projects is frequent change to project scope, software estimation methods should provide extensive support for managing those changes—in addition to supporting negotiating changes to the project scope. For example, by carrying out function point sizing (e.g., ISO 2005, 2009) at different points during software requirements analysis and design, it is possible to have a quantitative measure of any changes to the project scope (size) that are occurring as the work continues. Note that measuring scope should be a part of the systematic change management process, where the impact of change on the scope (and other project constraints) must be assessed and accepted before it is implemented. 2.3.6 Reducing Management Overhead Last but not least, one of the primary business objectives of commercial organizations traditionally is minimizing costs. Therefore, software practitioners expect effort estimation not to impose much overhead on the project and development team, for example on average, 6 % of total project cost (Trendowicz 2008, Sect. 2.3). 2.4 Estimation Life Cycle Your task is not to foresee the future, but to enable it. —Antoine de Saint-Exupéry Following well-defined systematic development processes is considered key to successful software development. Yet, the key role of well-defined and lived project management processes is typically not as obvious nowadays. Too many projects still fail because estimation and planning are treated as a necessary evil and performed in an ad hoc manner. Project managers seem to be oblivious about the existence of estimation processes and their key role in overall project success. In this section, we introduce a basic estimation process and discuss its key elements in the context of associated project management activities. 2.4.1 Defining Estimation Process Figure 2.4 illustrates an abstract software effort estimation process. In the define project step, a project manager defines the scope of the software project. User requirements regarding the expected development outputs and characteristics of a project environment are the starting points for defining a project’s scope. Based on this information, the project manager specifies detailed development