Original Post Date: Thursday, September 27, 2012

I am frequently questioned by clients and prospects about the applicability of PRICE’s parametric software estimation model to agile software development projects. 

There are several ways one could respond to this.  My first thought is that if a shop is truly agile, they don’t need an estimation tool.  They know their development team velocity because agile teams are committed to measurement.  They also either know when they need to make a delivery – in which case whatever amount of software they’ve build by that point will be released.  Alternatively they may know a minimal feature set without which the product will not add value to the customer base – in which case whatever amount of time it takes to get to that minimal feature set is how much time will be spent (with the understanding that being agile means even this minimal feature set may be redefined by the end of the project).  The nature of agile development requires estimation to be done on a very low level and be applied only to the user stories involved in the current iteration.

This answer, while generally acceptable to the development team, is often a bad answer for the business that needs to develop plans and create splash and sparkle around an upcoming software release.  The business needs to have a good idea when software will be delivered and what sets of features they can expect to be in that software.  To folks with these requirements my answer to the above question is a resounding YES.  In fact this is a perfect application of parametric estimating techniques because it allows for a union where the forecasting minded business side of the house can apply what they learn from the measurement committed development team to the experiential knowledge and requirements that they bring to the table.  This creates an environment where a plan can be formed based on the business’s best guess of what the final product will deliver along with some hard firm data about the productivity the team has been able to deliver in the past.

The next obvious question is how to ‘tell’ the parametric model that an agile development technique is being employed and how  to translate from story points to a more traditional unit of software size measurement.  To questions such as this I am quick to point out that agile development is a paradigm based on a set of tenets written by some pretty smart software dudes.  Different agile shops employ different practices and it is a thoughtful understanding of the software being developed and the practices that are employed that will lead to success when one is applying parametric techniques to estimate software cost and effort.  As with so many other aspects of software development, there really is no magic bullet to up-front  estimating of a software project, whether or not it is an agile project.  For more on this topic check out my paper "Are Parametric Techniques Relevant for Agile Development Projects”.

How does your business handle the potential conflicts between employing agile principles and creating credible plans for affordable and successful product deliveries?