Software estimates: the total cost of Agile projects

Estimating the cost of software is, at best, an educated guess.

We try to pretend this is not the case, yet despite all the new ideas and models, software is still costed in the same way it was when I left university 20 years ago. There are so many complexities in software estimates that it ultimately relies on the judgement and informed opinion of the software creator.

Errors detected during requirement phase account for 40%-60% of defects.

We typically estimate software by doing variations of the following approach:

  1. We deconstruct the software system along functional boundaries. This is simply functional decomposition of the system, and the result is often a requirements document. We often have a different understanding to that of the customer, so requirements documents are often a ‘best first guess’ of what the system needs.
  2. Programmers estimate how long it would take to build each component.
  3. Some contingency factor is then applied. This contingency factor goes by various names such as ‘transactional complexity’, or ‘risk assessment factor’ and are gross multipliers often by up to +/- 150%.

The result is an software estimate that can vary by +/-50% of the final cost. This is such a large margin of error that I would consider it a good guess and nothing more. In comparison to a real science, we know the speed of light to an accuracy of plus or minus one part in 300 million [1].

Professional consultants will point out that 100% of their project are exactly on budget, but this is often done by false accounting. For example, the quote any changes to the initial requirements as a separate project even though the we know that the initial requirements are incorrect by 40%-60%. In an even more egregious example, software might be released on time to the client, but with known defects (i.e. the quality of the product is compromised to meet the time, cost and scope parameters).

The true cost of producing software is hidden by shifting work between different cost centers, or by re-defining what’s ‘in scope’ [also know as finessing scope]. It’s an accepted way for suppliers and customers to lie to each other.

Estimating the total cost of Agile projects

Questions about how to estimate the total cost of Agile projects are questions about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous, so I wouldn’t encourage them.

How would a team estimate the cost of fixed-scope work upfront? Here are several approaches for you to consider:

Estimate the project the same way you currently do. If the approach that you’re using provides enough accuracy and you’re able to make a profit, then why change? Any other approach is as likely to be as inaccurate as what you have now.

Estimate the project using a coarse scale … such as T-shirt sizing, and then assign a dollar range to each size. For example, have the team work with the product owner to create a list of User Stories at a high level (epics). The team then estimates the epics on a very coarse abstract scale such as T-Shirt sizes ranging from XS through to XL [XS, S, M, L, XL]. Because we’re only concerned with order-of-magnitude and not about accuracy, this should be a relatively quick operation.

We would then assign a dollar range to each size on our scale; XS would be $10,000-$20,000, S would be $40,00-$80, 000, M would be $150,000-$200,000, etc. We would tally up the final figure to give an upper and lower bound for the total cost.

If the customer wanted a fixed price project then we would quote the upper bound figure to compensate us for the additional risk that this might incur. If they’re willing to work on a more flexible basis (say fixed-cost, variable-scope), then we could consider a quoting a lower cost.

Change the conversation. Changing the conversation is my preferred solution, because changing the conversation helps to educate the client that Scrum is more than a different way to do the same old thing … rather it’s systemic change.

This approach is also the most difficult.

To use it effectively requires a mature understanding of the different arguments for and against. It is also a realistic answer to the question of how to determine the cost of software upfront. We don’t know [although we can provide educated guesses].

A more meaningful question is how much does the client value the new software? If the client is unable to answer that question, then perhaps the new software has no value at all and is not worth creating. If the client has an understanding of the value of the software (perhaps through a cost/benefit or ROI analysis) then the breakeven point should serve as then upper bounds of the teams budget.

Taking this approach is not without its risks. There is certainly the possibility that the client will decline our services. Mature agile consultancies understand this and are often willing to walk away from work that results in a mutually disadvantageous arrangement.

A way forward

This post has likely raised as many questions as it has answered. Let me finish by providing a glimmer for a way forward … Agile companies tend to form strong, long-term relationships. How to do this will be the topic of my next blog post(s).

References

[1] “Speed of light” from Wikipedia.

, , , , , ,

4 Responses to Software estimates: the total cost of Agile projects

  1. mysticsymphony February 20, 2014 at 8:57 pm #

    scrumology mysticsymphonyThanks for the info.

  2. scrumology February 20, 2014 at 4:17 am #

    mysticsymphony  I’m not an expert on Function Points, so I cannot comment on that point directly. However, doing Scrum with a Fixed Priced contract is a really bad idea. I wrote about it here: http://scrumology.com/scrum-and-fixe…rice-contracts/

    And I presented some alternative contracts here: http://scrumology.com/an-overview-of-agile-contracts/

    Finally, did I mentioned that doing a Fixed Price contract with Scrum is a ready bad idea?

  3. mysticsymphony February 20, 2014 at 3:24 am #

    Hi,Thanks for the article.I am new to Function point and I stumbled across this article in my research on FP estimation.Majority of projects in our company are small scale and are in the Fixed price model. We are implementing Scrum here gradually. My doubt is, will these work together – Function Point Estimation+Fixed Price Projects+Scrum ? The constraints here are, the level of details we get before a project might be very less during the estimation phase. The screens might not even be there.Mostly, it will be a very high level list of features of the product based on which we have to provide estimates.The cost estimate of the entire project has to be given to the client before the contract is awarded.Can estimation and requirement analysis happen in an agile way in such an environment ? And if it can happen then is it feasible to use Function Point estimation technique within these constraints we have ? Any thoughts? Thanks in advance.

  4. @snunsan December 20, 2012 at 6:27 pm #

    Estimating the total cost of #agile projects is tough: one useful tip is to take several approaches and get the mean http://t.co/hbz0tjbh

Read previous post:
Guest Post: Dealing with Split teams and Communication

Today we implemented a blanket Ban on emails! We have a situation where our team is split between two locations;...

Close