How do you estimate an Agile software development project?

Agile software development emphasizes the evolution of requirements and solutions through the collaborative efforts between the development team members and the project’s customers. These teams are cross-functional and self-organizing, standing in sharp contrast to traditional development teams. The Agile methodology advocates an adaptive approach to planning that values early delivery and continual improvement, even when user requirements change frequently. The Manifesto for Agile Software Development describes the values and principles of Agile development, which is based on earlier frameworks such as Kanban and Scrum.

The Agile principles can give the impression that Agile software development doesn’t involve long-term planning. However, planning is actually a critical function that requires managers to achieve a high level of understanding about the project early in its development. Managers of Agile programs must develop answers to questions about what they plan to deliver, when they plan to deliver it, how much it will cost and what the benefits will be. Stakeholders use these answers for a variety of purposes such as justifying the initial investment in the project and its ongoing maintenance costs.

Background

The concept of iterative, incremental software development methods originated as early as the late 1950s, which was originally known as evolutionary project management. Methods of adaptive software development began to emerge during the 1970s, although it wasn’t until the early 1990s that truly lightweight development models such as the following became available:

• Crystal Clear

• Dynamic Systems Development Method (DSDM)

• Extreme Programming (XP)

• Feature-driven development

• Rapid Application Development (RAD)

• Scrum

• Unified Process (UP)

All of these methods predate Agile development itself, although they’re now considered Agile development methods.

A 2001 conference on lightweight development methods resulted in the publication of the Manifesto for Agile Software Development, which still provides the standards for Agile today. Another developer group wrote an addendum in 2005 for performing project management according to Agile methods. An extension to the Agile manifesto was released in 2009 called the Software Craftsmanship Manifesto, which the established guideline for professional conduct in Agile development. The Agile Alliance published its Guide to Agile Practices in 2011, which is an open-source compendium of Agile practices and experiences from Agile practitioners.

Agile Values

The 17 signatories to the Agile manifesto proclaimed their values based on their professional experience in developing software. These values describe the four differences between Agile and the traditional waterfall model for software development.

For example, Agile values individuals and interactions over tools and processes. This value doesn’t mean that tools and processes are unimportant, but it does mean that they aren’t as important as having a team of competent people working effectively as a team.

Agile also values functional software over comprehensive documentation. It still requires documentation to help people understand how the software is designed and how to use it, but the primary purpose of software development is to create software rather than documentation.

Another Agile value is emphasizing customer collaboration over contract negotiation. Contracts are still required in Agile, but they don’t replace the need to learn what customers want.

Agile also values responding to change over following a plan. A project plan is still required, but it must be sufficiently flexible to accommodate changes in technology, user priorities and the operating environment.

Development Process

Agile development generally breaks a project into small iterations, or sprints, to minimize the amount of design and planning that needs to be done upfront. Sprints typically have a time frame of one to four weeks, which are completed by a single team that performs all functions, including design, coding, testing and acceptance. The team then demonstrates a working product to stakeholders at the end of each sprint to minimize risk and keep the project adaptable to change. Sprints don’t need to add enough functionality to warrant a market release, but they should produce a reasonably bug-free release.

Co-location is one of the principles of Agile development, which requires team members to work in the same physical location. This practice creates a team identity and improves communications due to the face-to-face interactions. It also reduces cycle times, since discussions aren’t mediated through communication channels such as phone, chat or email.

Agile teams must include a customer representative that may be known by various other names, depending on the specific development methodology. For example, this person is known as the product owner in Scrum. Project stakeholders select the customer representative, who must remain available to the developers’ questions throughout the sprint. The customer representative reviews the project’s progress with stakeholders at the end of each sprint, primarily for the purpose of re-evaluating priorities if necessary. The most common reasons to change priorities are to increase the project’s return on investment (ROI) and ensure the customer’s requirements remain aligned with organizational goals.

A physical display known as an information radiator is an essential element of Agile development. It’s prominently located near the development team and provides a current summary of the project’s status. The information radiator often uses lights or some other visual indicator to make the status clearly visible to passers-by.

Agile projects have a short feedback loop to improve the team’s adaptability to change. A brief daily meeting also known as the daily scrum consists of involves each team member reporting on what they did the previous day and what they intend to do today. They also need to report any impediments to their goal at the daily scrum.

Agile development also relies on a variety of techniques to improve code quality and increase the project’s agility. These techniques include automated unit testing, behavior-driven development, continuous integration, domain-driven design and test-driven development. The overall goal of these techniques is to build quality code, which developers can demonstrate for customers by the end of the sprint.

Analysis

An analysis of a program’s costs and benefits serves a variety of specific purposes in Agile development, especially during the acquisition phase. Cost and benefits estimates help project stakeholders perform assessments such as an Analysis of Alternatives (AoA), Business Case Analysis (BCA) economic analysis (EA) and life cycle cost estimates (LCCEs). A comprehensive assessment methodology is also necessary to persuade senior stakeholders to relax oversight over the project. Furthermore, assessments also help provide cost information that will increase the product’s performance through continuous improvement.

The quality of these assessments generally improves over time as more information about the project becomes available. Assessments should consider the agile development process, which will generally provide limited information during the sprint. Once each sprint is completed, however, more detailed assessments should become available before beginning the next sprint. The specific costs and benefits of Agile development vary greatly due to differences in the complexity, scope and size of these projects. However, several factors determine the value of agile development as compared to traditional development methodologies.

For example, the degree of Agile enablement on the part of stakeholders and external processes has a profound effect on the ability of Agile to benefit a project. The quality and experience of the team members are also critical factors in obtaining the maximum benefits of agile. The cost benefits of agile development also depend on the specific methodologies used and the compatibility of the requirements and constraints of the program with agile methodologies.

The techniques for realizing data in the cost and benefits of agile development are still maturing, especially for government projects. These estimates and assessments should also consider the extent to which Agile best practices will affect the project’s costs and benefits, as is the case with all software methodologies.

Approaches

The major approaches that project managers use to estimate Agile software development include analogy, engineering build-up, extrapolation from actual costs and parametric techniques. The best method primarily depends on where the project is in its development life cycle. For example, project managers usually begin with an analogy of costs since its definition will typically be limited. As the acquisition program matures and real data becomes available, cost estimation methods can use actual cost and other data from the completed phases of the project to estimate costs for the remaining phases. Cost estimates thus have a great degree of uncertainty early in the project that become more certain as its risks materialize.

The basic techniques for estimating costs in an Agile project can be the same as those used for traditional software development. The primary difference is that Agile projects aren’t as well defined when they reach the development phase as those using traditional methodologies. Agile project in the early stage of development must therefore rely on analogy techniques more heavily, which are largely based on the product vision and roadmap. Project managers can apply engineering build-up methods later in development, which uses data collected from product releases. Cost analysis can then focus on estimating the work that can performed with available funds once the major costs have been fixed.

Cost estimation requires a more iterative, collaborative approach than traditional acquisition methods. Traditional programs typically treat cost analysis as separate from development, whereas these two activities are both team-based activities in Agile. Cost estimation should ideally be closely tied to the development of each release, allowing cost estimators, developers, users and other stakeholders to collaborate closely to ensure agreement on the prioritization of requirements. This approach provides team members with a thorough understanding of the resources that will be needed to complete each release. It also allows risk assessment to be integrated with the driving factors for costs, performance and schedules.

Product size is usually the most important driving factor for the cost of software development, regardless of the specific methodology it used. Agile uses stories to define requirements, which are similar to use case descriptions in traditional development. A story point is a metric that team members use to estimate the difficulty of implementing a given story. Agile development has a greater tendency to use cost estimating strategies that are based on relative measures of size like stories, rather than absolute measures of size such as lines of source code.

Agile methodologies don’t define the size of the story, so development teams must reach a consensus on the number of points that each story should have. Team members estimate the points for story based on the effort needed to develop each featuring a story, including relative complexity and risks. A common approach to this task is to assign the project’s simplest story the value of one point. From this basis, the members would typically assign point values for at least a medium and hard story, thus providing a relative means of comparison for story difficulty. Some scoring systems are also based on other measures of complexity such as a Fibonacci series or ideal days.

After an Agile team develops the stories for a project, it must prioritize them into a list known as the story backlog. Each release will be comprised of a number of stories based on the sprint schedule and measured against the team’s progress rate, also known as velocity. Agile program managers generally measure their team’s velocity with historical values or forecasts based on the team members’ experience and skill set with the relevant technologies. Once the team has completed the first sprint, it selects the stories that will be included in the next sprint based on the schedule and team’s velocity.Agile teams regularly reassess the story backlog based on the insight it obtains from previous sprints. This iterative approach increases the quality of cost estimates over time, although the details of the release-level estimates typically remain at a higher level than the sprint-level estimates. The team should also compare the estimates for a particular release with the effort actually required, adjusting for factors such as adding and removing stories from a release and changes in the estimating methodology. This process also helps track the overall progress of an Agile project.

Cost Factors

The cost impacts of Agile development may be classified into increases and decreases. The most significant cost increase for Agile is the initial investment needed to implement the development methodology, which in some cases requires ongoing expenditures. Once the team deploys a release, an Agile project should begin showing cost decreases as it reaches a sustainable state. Cost avoidance and cost savings are the areas with the most significant potential for cost benefits in Agile development. The areas with the greatest impact on costs in Agile include the following:

• Software development

• Integration and testing

• Deployment

• Training

• Program management

• User participation

Software Development

Agile team members continually engage users and solicit their feedback throughout the development process, which can increase the amount of unplanned work needed to complete each iteration. The reason for this increase is that Agile requires the development team to incorporate changes into the current iteration rather than addressing them after deployment, as is the case with the waterfall approach.

Iterations are also smaller in Agile development, allowing developers to increase productivity through the use of greater levels of cross-training. This approach can also reduce the increase in code that often occurs when developers are uncertain about user requirements. The regular prioritization of requirements to meet scheduling and cost constraints helps limit code growth, although developers must still account for uncertainty about program size to other reasons.

Integration and Testing

The biggest factor in estimating the costs of integration testing for Agile projects is the deployment of smaller iterations with greater frequency. A waterfall approach requires large groups of functionality to be integrated and tested at the same time, which increases the complexity of this phase. Developing techniques for detecting errors is also more difficult when the software size is large. The frequent testing that occurs in Agile also allows errors to be detected earlier in the development process, which reduces the overall cost of testing.

The cost of regression testing is typically much less in Agile development, largely due to its greater use of automation. Other methodologies also use automated testing, but rarely to the extent that’s common with Agile. This capability is essential for supporting Agile’s requirement for rapid releases of software.

Deployment

Deployment frequency can be a key driver to development costs, especially if developers must deploy each release onsite. Agile development typically includes the release of new capabilities every six to 12 months, which requires a more frequent consideration of deployment costs. Automated deployment is generally needed to support Agile’s short deployment cycle.

Training

User training can be asynchronous with software releases, although it becomes more challenging with shorter deployment cycle. Agile development typically involves more training deliveries than waterfall development, such that each release may require additional user training. The cost of training is especially high when training is performed onsite, since it takes developers away from their primary task of producing the next release. However, the deep involvement of users during Agile development can decrease the amount of onsite training needed.

Sustainment

Software applications must continue to maintain their present capabilities as developers deploy new releases, a concept technically known as sustainability. This requirement means that an Agile development project must evaluate cost changes due to multiple, frequent releases that may overlap. Agile releases are also highly automated in most cases, resulting in a higher error detection rate during development. This capability increases sustainability and reduces development expenses since errors are more costly to fix after software is released. The practice of continually engaging users in agile development also reduces the effort needed to enhance software during sustainment.

Program Management

The requirement for frequent customer participation during development has a great impact on managing Agile programs. Customers typically engage with developers on a daily basis in Agile and assist in a variety of functions such as creating stories, prioritizing requirements, acceptance testing and providing feedback on new capabilities. Specific customer roles on an Agile team include cost estimators, product owner, contracting officers, testers and users, all of which increase customer costs during development.

Cost Comparisons

Program managers often classify costs according their stage in the Agile development life cycle. However, they can’t translate cost impacts into real dollar values when the project is immature. Furthermore, many variables affect the cost analysis of each major cost area. The most common practice in Agile estimating and planning is to establish a relational scale that summarizes the general trends associated with each cost change as compared to traditional development models. This technique generally provides best and worst cases for whether a particular cost should be less than, greater than or about the same as the equivalent cost in traditional development.

For example, program management costs may be about the same in Agile in the best case, but slightly higher in the worst case. The most likely period for a relative increase in these costs occurs when program managers began incorporating the increased level of customer engagement into the project. Software development costs in Agile should be less than or equal to traditional development, such that a higher rate of requirement changes decrease the relative development costs. Integration and testing costs may be the same or greater for Agile, depending on the extent to which the project is able to automate testing to compensate for the increased deployment frequency in Agile.

The costs of fielding and deploying releases in Agile should be at least equal to that of traditional development, although they can be significantly higher due to the increased deployment frequency. The most significant factor in determining the amount of this increases the degree of on-site presence required from developers during deployment.

Sustainment is the cost area that provides the greatest opportunity for savings in agile appointment, with the relative cost change ranging from slight decrease to a significant decrease as compared to traditional development. Specific cost benefits of sustainment in Agile development include fewer defects and a reduced need for post-appointment enhancements. The savings in sustainment costs is realized over time, so systems with longer lifespans will provide greater sustainment savings.

Overall Impact

Agile development generally incurs a higher cost on the front end of the development cycle, but typically results in a net decrease over the product’s lifetime. Sustainment is the primary area where Agile development reduces a project’s overall cost, although the cost differences in major areas aren’t particularly independent. For example, fully realizing the reduction in sustainment costs due to increased code quality requires a large investment in automated integration and testing. Furthermore, the general cost impacts of the major cost areas are only a guide, as each Agile program has unique characteristics that will determine specific cost impacts.

Work Breakdown Structure

The work breakdown structure (WBS) is the cornerstone of every agile project. It describes the work needed to accomplish each program’s objective in detail by relating work elements to the end product, ensuring that no task is omitted or performed more than once. The WBS also provides program managers with a means of developing cost estimates by identifying required resources.

Many agile methodologies offer extensive WBS frameworks that allow developers to effectively define their activities and the tasks they still need to complete. These frameworks also identify breakdowns of current activity, which is essential in Agile development. WBS frameworks are readily available through open source and cost community forums, although they may not be suitable for a particular project. Team members may need to compile and modify existing frameworks to develop a comprehensive WBS that meets their needs. A project manager can then map this WBS to the common cost elements of the development life cycle.

A WBS provides a high-level structure for describing the products and efforts that will be required to complete an Agile project. It also serves as a reference that helps organizations transition to the Agile methodology by identifying actions to complete during development. Project managers who are new to Agile often build their WBS by mapping Agile-specific activities to a traditional WBS. On the other hand, managers may also combine non-Agile components to an agile WBS. The WBS should therefore become more detailed and customized for each project as managers gather more information about it.

An Agile WBS thus provides value for both program managers and developers by performing system-level and release-level functions. It also assists with tasks in different phases of a project’s life cycle, especially development and sustainment. This is a vital capability because all phases of the life cycle can occur within a single iteration, so the WBS must support the transition of activities from one phase to another. This characteristic means that generating a WBS requires developers to present activities in logical order rather than a chronological order.

Systems Engineering

Systems engineers (SEs) and members of the Program Management Office (PMO) often perform activities described by the WBS, even though they may not be members of the development team. These activities often remain unchanged in Agile, which typically include the following:

• Acquisition strategy

• Contract development

• Decision making

• Governance

• Resource management

• Roadmap development

SE activities that are unique to Agile include creating and maintaining the product backlog and defining when an iteration is complete.

Additional Activities

Other activities described by the WBS include release activities such as planning, executing and reviewing the release. Many of these activities may also be known as sprint activities when they occur within a sprint, where they have the additional goal of improving future sprints. Additional sprint activities such as engineering analysis, code reviews and experimentation are performed only on an as-needed basis in Agile, so their execution can vary according to the project. The WBS doesn’t specifically distinguish sustainment activities since they’re an integral part of the release. However, team members should include them within their appropriate elements when the life cycle transitions from development to sustainment.

Budgetary Alignment

The budget for an Agile project is based on its baseline requirements and the customer’s cost estimates. In addition to pure development costs, the budget must include the other life cycle costs such as planning, management, acquisition, maintenance and disposal. Agile allows program managers to structure the project to fit the budget, unlike traditional methodologies where the budget has to fit the project. The funding in an Agile project thus drives the frequency of releases in addition to the number of requirements within each release.

Agile programs must still track metrics to ensure satisfactory progress against the product backlog, despite budgetary constraints. Furthermore, the allocation of the program’s budget before its requirements have been completely defined can also present a challenge for some customers, especially enterprises accustomed to waterfall development. The customers often require additional time to understand the much lower maturity requirement for authorizing budgets in Agile.

Scaling

Agile programs scale more easily than traditional programs due to their highly iterative nature. The release frequency of an Agile program is at least one release every year, while traditional programs require at least five years to release a new product. This difference means an Agile program is more likely to have already provided the user with capability when it experiences a funding cut or cancellation.

Traditional waterfall methodologies fix the scope and quality of their projects. The cost and schedule of these projects generally increase as requirements are added during the project. In comparison, Agile projects adjust the scope of each release to fit schedule and cost constraints. The prioritized list of requirements defines the scope, allowing the development team to deliver functionality to the users that conforms to the constraints of cost, quality and schedule. Release planning is thus driven by cost in Agile development.

Budget Cuts

Agile programs absorb budget cuts more easily than waterfall programs because deferring a small increment has less impact on the user than delaying a larger one. This advantage is particularly important with software programs since they’re more likely to be cut than other programs that provide a faster return on investment (ROI). It’s therefore critical for software programs to obtain support from the customer’s highest organizational levels to minimize their risk of losing funding.

Projects that use Agile methods can adapt to both temporary and permanent budget reductions by decomposing the current project into multiple releases. This approach allows the project to deliver capabilities to the user more efficiently once additional funds become available. It’s much more difficult for waterfall-based programs to accommodate budget cuts from both a contractual and technical standpoint.

Validating Estimates

Project managers must assess a number of key factors about the development team to validate cost estimates for Agile projects. For example, the team needs a large amount of historical data before it can make reliable cost estimates, especially early in the project. Strong knowledge and extensive experience in the technologies the development team will be using is also a critical requirement for estimating costs. It’s also beneficial for the team to be knowledgeable and experienced in the user’s industry, although this isn’t always practical.

Program managers must also monitor and update the team’s velocity regularly in Agile projects. They must also use the velocity to determine the scope of sprints to validate cost estimates. Furthermore, development teams must use an estimation method that provides consistent cost values across similar projects.

Summary

Agile systems estimate costs in relative terms, rather than the absolute dollar values that traditional development methods use. The most common way to accomplish this is through the use of points, whether they’re functional points, user points or story points. Personnel factors are generally more important than project factors in estimating costs for an Agile project, including the knowledge and skill level of team members in addition to the degree of cross functionality needed for effective Agile teams. Additional Agile practices such as stories and planning games also improve the quality of work estimations.

Methods for estimating costs in an Agile project generally become more accurate over time as managers learn more about the project. Selecting the cost estimation method based on characteristics such as business area or team size can also improve estimates. Another approach to achieving quality estimates for an Agile project is to modify existing methods for traditional development by predicting the cost differences of each major phase in the project’s life cycle.