Estimating the total cost of Agile projects

# Estimating the total cost of Agile projects

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.