"Ok, so Agile is a great way to develop software", you say, "but how do I sell it to my customers?". Most pricing models that I've seen don't balance risks fairly between the customer and the supplier. Either the customer or the supplier carries all the risk, which doesn't sufficiently push both parties to take their responsibility. In this post I describe a simple pricing model that I've applied succesfully, and that - I think - balances out risks more fairly.

The 'fixed-price, fixed-scope'-model

The 'traditional' approach is to agree upon a set of requirements with your customer, estimate the time it will probably take to deliver the requirements, and use some pricing model to arrive at a fee and a delivery date. In this 'fixed-scope, fixed price'-model, the supplier carries all the risk for budget overrun and uncertainty in requirements. This wouldn't be a big deal if scope is perfectly obvious from the get-go, and if the estimates are fairly accurate. But the reality of software development - and the reason why Agile software development came to be - tells us otherwise. And since something has got to give, quality is often sacrificed, along with the responsiveness of a supplier to new ideas and insights from the customer. The bottom-line is that this model doesn't establish a strong incentive for the customer to help limit, clarify and reduce scope.

The 'time & materials'-model

A model that is often used in Agile environments, and one that I've worked with quote a lot, is the 'time & materials'-model. In this case, the customer essentially buys a team (the 'materials') for period of time to work on a Product Backlog. In its purest form, there is no agreed-upon scope that has to be delivered; the supplier simply puts in their best efforts. Although this is an ideal model from the perspective of the supplier, it requires great trust from a customer. And - in my experience - it also makes the customer carry the entire risk for budget overrun and uncertainty in requirements. Furthermore, in this model there is no strong incentive for the supplier to help limit, clarify or reduce scope.

So, the 'fixed-price, fixed-scope'-model and the 'time & materials'-model don't work because they don't distribute risks evenly between both parties. A good Agile contracting model should make both parties equally responsible for limiting, clarifying and reducing scope, and distribute the risk of budget overrun and uncertainty in specifications.

The 'fixed-price per story point'-model

A contracting model that I have used on several occasions now, is the 'fixed price per story point' model. It starts by identifying a set of functional requirements for a project in the form of a Product Backlog:

The 'fixed price per story point'-model converts an initial Product Backlog to a price by converting the total number of story points to a price, based on a fixed price per story point (e.g. 500 dollars). This is comparable with how 'function points' are used, although far less formalized. There are several things I like about this model:

• It is very simple to understand and apply. I really like that this approach essentially breaks down a large project into a lot of small projects. Every item on the Product Backlog can be treated as a mini-project;
• It puts a good and healthy kind of pressure on a Scrum Team to deliver 'done' software with every item on the Product Backlog;
• The customer can easily predict the impact of re-prioritizing items or adding/removing items;

What I don't like about this model is that it doesn't take into account that a larger number of points essentially indicates an increasing uncertainty. It treats story points as a continuum of pseudo-hours, whereas story points are only ordinal categories of uncertainty (e.g. '5 points' is about twice as uncertain than '3 points', not exactly 1.67 times). Especially for large items on the Backlog, this model still goes along in the fantasy that software development is quite predictable.

The 'capped min/max-per-item'-model

I have good experiences with a variation of the 'fixed-price per story point'-model that adds a mechanism to account for the increasing uncertainty. For lack of a better term, I'll dub this the 'capped min/max-per-item'-model. It adds a 'min/max'-conversion model for classes of story points, like so:

Obviously, this conversion table should be tailored for the team at hand - this is just an example. Based on an hour rate, hours can then be translated to a min/max price per item. The supplier is paid at least the lower minimum number of hours, but at most the maximum number of hours. The risk for overrun on a per-item basis lies with the supplier, but this risk is mitigated by an increasing min/max-range as a function of growing uncertainty (as indicated by the increasing number of points). Using this model, the estimated story points for the items on the aforementioned Product Backlog can be translated to (rough) hour estimates (and thus prices):

I think there are several advantages of this model over other models:If a single hour is billed for 50 dollars, the project would end up between 4.500 and 8.200 dollars. Obviously, there is a huge margin in the larger items on the Product Backlog. If we would leave out the large item, the range would lie between 2.500 and 4.200 dollars. Since this model incentivizes the break-down of larger items to arrive at a more accurate price, it might be tempting to break down these larger items right away. In this case, we have to keep reminding ourselves that there is little value in detailed upfront analysis, especially if the item has a low priority and may (will?) be subject to change as our insight and understanding of the software grows as the project proceeds.

• With the added concept of min/max caps for story point categories, it is still easy for a customer to understand what's happening and how the pricing is calculated;
• It incentivizes both the customer and the supplier to put in their best effort to limit, clarify and reduce scope;
• It distributes risk more fairly between the customer and the supplier than the 'time & materials'- and the 'fixed-scope, fixed price'-models, and takes into account that risk increases as a function of uncertainty;
• Based on experience and measurements, the conversion table for points-to-hours can be updated to reflect the range in time it takes to deliver an item of (say) 5 or 13 points;
• This model incentives both parties to break down larger items on the Product Backlog in order to arrive at a more accurate estimate, which is exactly what we want to do in Agile Software Development;
• This model, like the 'fixed price per story point'-model puts a healthy, good kind of pressure on a Scrum Team to deliver working software for every item. The customer should be able to go live after completing an item;

I would like to hear your thoughts and experiences with a model like this. I don't think its perfect by a long shot, but it is sensitive to the needs of a customer (a scope, a pricing range and potentially a date) without losing the ability to change or re-prioritize scope. It facilitates an Agile approach, without placing the burden of risk entirely on one party.