To be presented during the 2019 International Forum on COCOMO and Systems/Software Cost Modeling, October 28th and 29th at USC…
Agile development practices offer a more practical approach to software development in many cases. Agile development processes rely on development teams communicating with clients to deliver software that provides the most value for the money spent. This requires a mind shift on the part of both the developers and consumers of software to accept the reality that things will change over the course of the project.
At any given time, the agile development team is only working on the feature that the customer currently feels is the most valuable. Estimation is performed by the development team and is only focused on the feature(s) that is currently on deck. At the end of each iteration, the customer reviews the implementation to date and can reprioritize remaining features. At this level, estimating beyond the current feature doesn’t really make agile sense.
Unfortunately, the fact that estimation may not make sense for the agile team does not mean it doesn’t make sense for the business or the program office. These folks need to be able to make business decisions based on likely outcomes and known risks. The good news is that with a truly agile project, cost and schedule are fixed. There is an agile team of a certain size, iteration lengths are pre-determined, and the release cycle is fixed. The estimation question is now “How much can the team fit into the next release and how many iterations or releases will it take to accomplish what they plan to accomplish?”
This paper discusses the agile software development process and presents a methodology for creating estimates that inform decisions makers of what to expect from their agile teams. The methodology assumes that team size and release cycle are known quantities along with an ‘estimate’ of the amount of functionality anticipated. This information, along with other program and project parameters, is used to determine the number of iterations and releases necessary to achieve the goal. This methodology will be presented, and a potential implementation of this methodology will be demonstrated.