Wednesday, May 09, 2012

Agile and Cost Breakdowns

At the beginning of an Agile project it is often very tricky to provide a cost breakdown for individual items of work. This is because central to the Agile methodology is the demand that at the start of a project everybody admits they do not really know what details to expect! This is a brave thing to do. It is brave of a developer to admit that the implementation details of a proposed project are not clear. It is brave of a client to accept that they do not really know, in real-life detail, what it is they want. The pay back for all this honesty is a much better chance that the project will be useful, delivered on time and delivered within budget.

That said, many clients require the sort of detailed costing that Agile does not supply. In response it has become common to adopt the following approach: Each unit of work is assigned a number of points where the more points the more difficult the task is considered. This number encapsulates all the experience of the developers, their previous projects and their expectations for the current project, however it does not directly relate to cost. Instead, as the project unfolds so the developers keep careful track of the effort required to deliver each unit of work. This creates a relationship between the points and the actual, real-life cost of delivering those points for the current project under the current conditions. As the project continues the mapping between the abstract points and the concrete costs becomes ever more accurate and useful. This is in direct contrast to other project management techniques where, as the project unfolds, the predictions made at the start become ever more inaccurate and useless.

This still does not answer the client’s needs however. They need a hard and fast prediction, an amount of cash per unit of work, a crystal ball that allows them to peer 6 months into the future and follow the convoluted, unpredictable, surprise strewn trajectory of a hand-made, complex software artefact that, as yet, nobody can truthfully define in detail. As unfair as it may seem, the business demands that we need to answer the following question: “How much will it cost to build something you don’t really understand, given that you don’t know how long it is going to take and given that what is possible and what is desired will certainly change along the way”. The answer has to be “I don’t know”, any other answer is a guess.

Can we do better than guessing? Yes, a little. We know the total (estimated) number of points. From this we can generate a cost estimate, informed by experience, for a total cost expressed as a min->max range. A detailed breakdown of costs can now be derived (for what it is worth) by simply dividing the range values by the total number of points to give a min->max range per point. From this a cost value per unit of work can be estimated. For example:

Total Points for Project = 100 
Estimated Total Cost     = 30K -> 45K 
Estimated Cost per Point = [30K / 100] -> [45K / 100]
                         = £300 -> £500 per point

This estimate will be wrong but, because this is an Agile project, as time goes by the estimated costs will become steadily more accurate. This is good, because most of the cost overruns on a traditional product come near the end. In contrast, the final stages of an Agile project are the least risky and the most productive. This is when everybody finally understands what the project is about, the client knows what is possible, the developer knows what is required and given this shared knowledge, both realise there is more that should or can be done – budget allowing.