Agile Estimation: Are We Asking the Right Question?

August, 2013 

 

There seems to be considerable debate and confusion surrounding the concept of estimation as applied in the agile world.  Many appear to argue that estimation has no meaning outside of the agile team, but sponsors and stakeholders need something to base their decisions on and estimation is a key component of it.  Perhaps we need to reengineer our definitions and objectives at the higher level. 

Typically, management wants to know how much X will cost and how long it will take to deliver before making the investment; where X is some bundle of deployed functionality with an associated business value.  Not an unreasonable request in a traditional environment where the application is the focus of attention. The investment decision is how much greater is the value than the cost (the ROI). Unfortunately, the estimation process is subject to considerable uncertainty prior to the initial stages of architecture and design (the uncertainty decreases with subsequent stages but does not reach zero until completion and deployment – and then the estimation of the O&M stage begins) – not a good foundation to base investment decisions on.  

If we change our focus from applications to delivering business capabilities and adopt an agile development process, the concept of estimation changes as well.  For example, in traditional (stovepiped) development much of the development is actually producing redundant functionality (in terms of delivering business and technical capabilities), but this is obscured by the focus on the app.  For example, all apps provide error handling and audit logging as well as security (authentication and authorization) – how many times have these been (re)developed?  The same applies to business-related capabilities.  If we can take a broad view of the capabilities required and identify sources for providing them, much of the development may be avoided altogether.  This, of course, is the benefit from adopting a SOA approach.  If we adopt an agile development methods and establish an agile team with an associated cadence, the estimation question should be something more like: how much value can we produce in a given amount of time?   Given that the team has a cost for a given period of time (say, a year), and each delivered business capability has a known value, we can still make investment decisions – what is the net value produced from the investment cost.  

Economics would say you should invest up to the point where the marginal value derived equals the marginal cost of producing the next increment of functionality (stories, capabilities).  From this increments perspective, we should expect the marginal value to be decreasing – because we are developing from the product backlog in order of priority – so we build the highest valued items first.  Marginal cost should be flat or decreasing as well – the cost of the team may be constant, but the cost of producing the next item may go down as we build up and consume more (pre-existing) shared services.   

So, the investment decision changes from: is it worth building this app?  to is it worth funding this agile development team for a year?  This approach can be applied to determine how big the team should be and even how many teams should we engage.  The value delivered should be maximized because the most valuable capabilities are delivered first (along with the capabilities they are dependent on).  This should hold even if the priorities change because the product backlog embodies those priorities.