The “agile” concept for Software (SW) development is not new. Federal government programs have been researching how they can adapt agile principles to their SW development programs for several years. It would be fair to say that for the government, most SW development programs are replacing their waterfall-based management approaches with agile approaches for program management and execution.
This transition to Agile has introduced changes that impact cost estimating for SW development and operations. Key agile characteristics impacting the cost of SW programs include the following:
- Development is mapped to short term release cycles/increments, focusing on the immediate cycle in-work, pushing planning for future cycles to occur just as the cycles are scheduled to start.
- Daily changes and dynamics occur in the order and priority for work to be completed in each cycle.
- Useable SW features are delivered to the end user as they are completed, and not at the end of a lengthy waterfall schedule.
- Effort is measured in hours, based on qualitative sizing (e.g., story points) that is relative to the specific SW and development cycle in-work.
Other considerations for cost estimating:
- Agile is a management paradigm, and not a new way to write code or a new programming language. Existing SW development CERs can still be used with agile programs.
- In an agile program, regular SW development activities still occur, but are enhanced by automated testing, more user interaction, and increased concurrency that delivers working SW into the user’s domain faster.
- SW development effort is still measured in hours, driven by the relative size of the SW stories to be coded.
- Work from the backlog pool is selected and sized to fit an increment time box, and teams cannot do more than they are capable of in any time box period (sprint, release).
- Any “capability” is not complete and ready for delivery to the user until it has been integrated into a deliverable working feature and fully tested by the development team and user.
- Defects slow down the process and may add work to the increment where they are discovered.
To accommodate these agile characteristics, PRICE first had to re-imagine sizing measures, allowing users to define qualitative size measures as described by a SW development team. Measures such as story points can now be calibrated to describe a velocity (effort per unit time) based on the type of SW being coded – lines of code, function points, use cases, RICE-FW objects, or whatever is appropriate for the SW being developed by that team.
We then created two new agile modeling objects, based on our standard SW estimating model, to ensure predictive models capture the cyclic dynamics of an agile program:
- A SW Development Model: basically, a description of the capabilities for a development team, including measures of their experience, team size, the SW item complexity (language, application), and productivity (the calibrated agile velocity described above.) Users enter the number of customized size units (e.g., story points) to be accomplished in the increment, which then enables a cost estimate that reflects the user entered productivity and complexity measures.
- A Feature Integration (Assembly) Model: describes a release iteration that includes the integration and testing of features comprised of one or more SW components.
The figures below for the SW Development Object show the type of inputs the cost estimator can manage in these models, and the reported metrics that can be used to evaluate the cost, size and schedule of SW components and integrated features.