Agile estimation and communication of price to customers

Question

I'm new to this Agile way of doing estimates. For a long time I have been working in the classical way of estimating the whole project up front (roughly).

Now I have started to look into the Agile way of making estimates, and I understand the quality it brings to the estimates. Anyway, I have not yet grasped the way I can communicate the estimates to my customers.

My customers are used to the old way. The say they want this and this done, please tell me how much (in hours) it will cost. I will then go ahead and make a series of "qualified guesses", and finally end up with a total of hours.

The customer then accepts this, and let me start working. In almost all projects I have been working on, the "Cone of uncertainty" is lurking, and the estimates rarely end up as first promised. Much of the time I also end up giving away hours for free, because the customers come up with tasks during the project, and say something like "this was a part the original estimate".

I therefor see a great potential using an Agile estimation method. My only problem is how I can get my customers "on board", since they are used to a figure up front.

Answer 1

TL;DR

The subject of how to price an agile contract is both too opinion-based and too broad for a single generic answer. However, a number of books touch on the topic, and there are certainly plenty of starting points to form your own process. I list some external references below, and include some of my own experiences and recommendations as well.

Some External References

Some places you might start researching the current body of thought on this issue include:

• http://www.xprogramming.com/ftp/Optional+scope+contracts.pdf
• https://www.scrum.org/About/All-Articles/articletype/tagview?tag=agile+economics
• http://www.infoq.com/articles/agile-contracts
• http://coactivate.org/projects/agile-contracts/money-for-nothing-change-for-free
• http://martinfowler.com/bliki/ScopeLimbering.html
• http://www.agilecontracts.org/agile_contracts_primer.pdf

A little searching will yield many more documents, articles, and blog entry results.

Some Distilled Thoughts

Some Types of Agile Contracts

Having been doing Scrum contracting for a long time, I have my own empirically-refined opinions on the subject. In general, if you accept axiomatically that agile frameworks trade fixed scope for incremental delivery and project visibility, then you can structure your agile contracts in a couple of ways:

• Shippable Increments

  In Scrum, you should be producing a shippable increment at the end of each Sprint. As a result, contracts based on a per-sprint or shippable increment basis are a great substitute for fixed-price contracts.

• Time and Materials

  Agile frameworks like Scrum provide customers and stakeholders regular inspect-and-adapt inflection points such as Sprint Planning and the Sprint Review. This allows contracts to be based on time and materials, but remain flexible on scope throughout the lifetime of the project. The client can then declare victory whenever the project has delivered sufficient value, or cancel the project whenever the costs exceed the expected return.

• Fixed Iterations

  Yet another option is fixed time and flexible scope. For example, a client may present a backlog that the team estimates at 26 sprints. The contract can specify a fixed number of sprints, and then the client and team work together to maximize the value delivered within the agreed-upon number of iterations.

I tend to prefer time-and-materials or fixed iterations in my own contracts, but your mileage may certainly vary. There are certainly other ways to structure such contracts; you need to find out what works best for your organization.

Hard Requirements for Agile Contracts

In my opinion, the only truly fixed requirements of an agile contract are that the contract must:

• Foster collaboration between the team and the client. (See customer collaboration over contract negotiation.)
• Provide for changes in features or scope, because that's the very definition of agility. (See responding to change over following a plan.)

Agile projects are still constrained by the iron triangle. You cannot contractually constrain a project in all dimensions (e.g. time, scope, and cost) simultaneously and still expect success. Because agility is about embracing change, I personally recommend leaving scope as the unfixed dimension.

It's certainly possible that there are edge cases where it's best to fix scope and unconstrain one of the other dimensions, but in my own practice that has rarely been the best choice when following Scrum. Your personal experience might differ.

Answer 2

Strive for a collaborative partnership model

You should strive for a partnership model where your development team is able work closely with the customer towards project success. Try the points suggested here in your pitch: Your Argument against Waterfalls: Reduce Waste

• With waterfall-like methods, all good ideas must come at the beginning. A great idea in a late process cycle is treated like a threat. Does that really make sense? What about the "aha" effect when people first see and try project results? Best ideas often appear during the first hands-on experience.
• With waterfall we see the risk of delivering what has been originally asked for (“written in stone”), not what is needed.
• At the end of the day the whole idea of agile development is to reduce waste. We don‘t want to produce more than we really need.

If you are able to persuade your customer, then you can go with either of these types of contracts:

• Capped T & M: This is T & M (Time and Materials) up until a fixed agreed upon upper bound (or cap) to protect the customer by providing a limit to their total exposure.
• Incremental Delivery: Structured with regular inspection points, and at each inspection point the customer makes a decision; they can continue with the development of the product or they can stop development.

If you are not able to persuade the customer, then you may have to consider the Fixed-everything project approach suggested here. However, make sure to follow the rigor of the process recommended for arriving at velocity to form the basis of the cost and schedule.