Want to talk Agile estimating? Well... The conundrum around software estimation is that at the point at which initial estimates are expected, the information about the project is often incomplete. While one could argue that this is true with all estimates, the fact that the project is software intensive increases the estimate complexity. Unlike hardware, software is hugely malleable – creating an environment where change in requirements is highly likely. This is true even in instances where requirements are ‘frozen’ at time of contract initiation.
A further complication arises for the estimator when the development team declares agility. In truth, if the team is truly agile, the estimate is easy. The release cadence, team size, team composition and schedule are predetermined; the estimate is an easy application of math. Most agile teams are not quite that agile, especially in the government space. Most programs are held to schedule constraints, firm fixed price and/or relatively fixed requirements. These teams are taking advantage of agile best practices to increase productivity or improve customer satisfaction, but they are still required to adhere to contract constraints.
How is the estimator expected to adapt estimation methodology to the agile project? First job is to figure out what the development team means when they declare they are agile. If they are truly applying ‘utopian agile’ the estimator’s job is to provide some credibility to the project. They know the team size, the length of iterations, the delivery date, the release cadence, the expected functionality, and the agile practices employed. In this case, the estimator’s job becomes one of creating an estimate based on this information and providing development team with advice about schedule feasibility and risk of delivering expected capability.
In the case where the agile team is at the other end of the spectrum – applying agile practices but not adhering religiously to the manifesto, estimation requires a more traditional approach. What the estimator knows is the capability requirements, schedule constraints and the agile practices that will be applied to the project. This creates a more traditional estimation scenario. At this point the estimator should apply what they know about the project, augmented with information about the agile practices employed, to their traditional estimating process. There is, however, a potential benefit to the estimator in this scenario. Teams applying agile practices are more likely to engage in significant metrics collection of things such as velocity, burn down, defects, etc. So, the results of traditional estimation techniques can be compared to actual values collected by the agile team and can work with the team to converge on a realistic and defensible estimate.
It doesn’t end there though; Another thing that the estimator needs to understand in either of these scenarios are the potential impacts of the application of agile practices. Do they improve or detract from productivity, are they more likely to improve quality, what other impacts might there be and how should these be included in the estimate?
Improve your program planning, decisions, and outcomes by using TruePlanning, part of the Cost Engineering Toolkit. Dynamically link cost, schedule, and uncertainty to technical requirements, including analysis, design, implementation, and verification. Leverage predictive power delivered through an integration framework, supervised predictive models, data analytics, cost element mapping, and enterprise data integration to provide total lifecycle estimation.
.jpg)
.jpg)
