Last tuesday’s meeting at the BayAPLN was a talk by Jim Highsmith entitled ‘Beyond Scope’. The talk itself was very interesting and did trigger some thoughts that I will try to organise in four or five posts. This first one is about cost.

How is cost estimated ?

There are numerous articles, methods and even books that describe how to do cost estimation for agile stories. In my limited world the consensus seem to be that cost estimation should be relative rather than absolute. It can be expressed with numbers or words. It also seems that one of the preferred methods for cost estimation is the planning poker. In that space more formal methods have been proved to work although they are rather tedious to practice.

Cost estimation for planning

Usually it is used to give an estimate of when the project will finish. As it happens, in software intensive systems, most of the operating expense is the payroll and so setting the length of the project is also essentially fixing its cost. And in many cases people will jump from one notion to the next. Now the trick is that to go from relative cost estimation to cost planning, some time equivalence has to be defined.

While we all know that circumstances (such as technical debt, absence of key team members and the colour of the sky) will make these equivalences vary over time, they are usually used in a normative way. In other words the team’s performance will be evaluated with regard to its ability to match the equivalent time that was initially chosen. In the worst cases it will be used to perform individual evaluation.

Cost as a proxy for value.

This however is a minor managerial effect. Use of cost estimation has a few implications of its own. First, while this is rarely expressed it means the scope is set. Otherwise, the planning is meaningless and what use do we have of the cost estimation ? I hear your answer: to give the business an idea of how to prioritise the stories. I was more than once on the losing side of arguing the business should prioritise before cost is known. In other words, cost is used as a proxy to value.

Is cost a good proxy for value ? Is something expensive a worst value than something cheap ? Or the contrary ? Worse, in a software system actual cost is usually dependent on the sequencing of stories. Or on how many stories a structural cost can be amortised.

To sum up.

Cost estimation is easy to come up with. It appears to be an easy control variable to measure the performance of the development process. It also appears to be an easy indicator to determine the priority of stories. In reality, is it good at any of that ?

This entry was posted on Monday, February 22nd, 2010 at 8:04 pm and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.