Estimating Software Development Effort

Once the initial software size estimate is complete, it can be converted into software development effort—an estimate of the resources needed to develop the software. It is important to note whether the effort accounts only for the WBS elements associated with the software development or also includes all the other non-development activities.

The level of effort required depends on the type of software application being developed. For example, real-time embedded and systems software, such as safety critical applications, typically requires more effort than automated information system applications of the same size because of stringent quality and certification testing requirements. Moreover, operating systems that must reflect real time updates and great reliability need more careful design, development, and testing than simple software systems. Variations in activities can significantly affect overall costs, schedules, and productivity rates, so it is critical to appropriately match activities to the type of software application in the estimate.

To convert software size into software development effort, the size is usually divided by a productivity factor, for example the number of source lines of code, or function points, developed per labor work month. Other factors that may affect productivity include the language used; whether the code is new, reused, or auto-generated; the developer’s capability; and the development tools used, among others. Historical data from a similar application can support the estimate or factor that represents the development environment. Absent historical data, an estimator can use a factor based on industry benchmarks, although this can add uncertainty to the estimate.

Agile software development takes a different approach to estimating software development effort. Agile developers typically rely on relative estimation methods to determine the software size. First, since effort is commonly used as a proxy for cost, estimating effort can not only determine the program cost, but it can also reasonably predict how long both near-term and long-term deliverables may take to develop. Second, understanding the capacity (or the total amount of work that Agile teams can accomplish in one iteration) helps prioritize work and predict the cost of a delay when “must-have” features cannot be accomplished as expected. Finally, having the Agile team commit to near-term deliverables is important because those commitments materially affect customer planning and business objectives while at the same time make the Agile development team accountable for their work.

Agile program cost estimates have an advantage over traditional program cost estimates because they are regularly updated to reflect changes in accordance with the program cadence. Agile’s regular cycle of iterations and releases provides numerous opportunities to continuously refine the estimate based on learning what the customer wants. However, there are many different ways to employ relative estimation which may not be consistent across different Agile projects, or even across different development teams working on the same Agile program. Like traditional software development, consistency in the counting method is key to developing a reliable sizing estimate.