Fixed-price contracts and Scrum

The buyer wants to know what it will get, when and for how much. The supplier wants to be paid for what it builds, and not blamed for what it was never told. A traditional fixed-price contract answers both with a detailed specification. Scrum says the specification will change, because the work is complex and understanding grows. The meeting of these positions is one of the most practical problems in agile delivery.

The conflict

Three variables define a project: scope, time and cost. A traditional fixed-price contract fixes all three, which leaves quality as the only variable that can quietly give way. Such contracts aim at minimising the risk of unpredictable, later changes, and for that they usually require a detailed and exact description of the subject matter in advance.

The SBOK® Guide states Scrum's different emphasis. To deliver the greatest value in the shortest time, Scrum promotes prioritisation and time-boxing over fixing the scope, cost and schedule of a project. The traditional approach, it says, emphasises fixing and managing those three, and may lead to a situation where the plan has succeeded yet the customer is not satisfied.

The Scrum Guide says that during the Sprint scope may be clarified and renegotiated with the Product Owner as more is learned, and that the Sprint Goal gives flexibility in the exact work. At product level, the Product Backlog is emergent: it changes as the product and the environment change. A contract that cannot accommodate this turns every discovery into a dispute.

Four contract shapes

The shapes below are common in practice, and some are described in the literature on agile contracts.

1. Time and materials. The buyer pays for the team's time at an agreed rate. Scope is free to change. The buyer carries the cost risk, and the supplier has little incentive to be efficient. Simple and a natural fit for Scrum, but buyers often resist the open-ended cost.

2. Capped time and materials. As above, with an upper limit on what the buyer will pay. The supplier benefits from early delivery within the cap, and the buyer has a ceiling. The scope that fits within the cap is what is delivered, ordered by the Product Owner.

3. Fixed price, fixed time, flexible scope. The price and date are fixed, and the scope is a ranked list. The supplier commits to the team and the time, and delivers as much of the ranked list as fits. Items below the line are not promised. This matches Scrum's time-box logic and the MoSCoW way of treating a fixed timebox. See MoSCoW prioritisation.

4. Agile fixed price, with a checkpoint. A model described in the literature on agile contracts. Instead of an exact description, the parties agree a broad description of the whole project and an indicative fixed price, not yet binding. A test phase follows, in which actual implementation begins. At its end both parties compare the findings with their assumptions and together decide on the rest of the project, setting the conditions under which changes are permitted. Further elements include sharing the cost of unexpected changes between the parties and exit points where either may leave.

A fifth variation is a series of small fixed-price contracts, each for a few Sprints, with a decision to continue at each end. It limits risk for both sides.

What every shape needs

A shared view of what is fixed. Say clearly whether it is price, time, scope or a combination.

A ranked backlog as the scope. The Product Owner owns the order. The contract refers to the list and not to a frozen document.

A change mechanism. Changes happen by adjusting the backlog, with a rule for what happens to price. For instance, an item is swapped for one of equal size, or added at an agreed rate.

Regular checkpoints. After a few Sprints, parties review progress with real data and decide whether to continue, change direction or stop.

A Definition of Done in the contract. So that "delivered" means something.

Access. The buyer's Product Owner must be available to the team. The supplier cannot build the right thing without them.

Exit points. The ability to stop at a Sprint boundary without penalty reduces the fear on both sides.

A worked example

This is an illustrative project. A company wants a customer portal. It has a budget of 300,000 and wants a date in six months. A supplier proposes a team of six for six months.

Option A is a traditional fixed price. Both spend weeks writing a specification of 140 pages, and the supplier adds 20 percent for risk. By month three the buyer learns that customers want a different sign-up flow. A change request is raised, priced and disputed, and takes a month. The portal launches a month late with features nobody now needs, and both sides are unhappy.

Option B is a fixed price, fixed time and flexible scope. The contract names the team, the six months and the price. The scope is a ranked backlog of 60 items, with a forecast that about 45 will fit. The Product Owner is a named person at the buyer, present at every Review. After Sprint three, customer feedback leads the Product Owner to replace six items with three new ones. No change request is needed, since the price is for the team and time. At the end the portal delivers 44 items, including the new ones, three of which were not in the original list, and the most valuable 38 of the original. The buyer is satisfied that the money went to the best use.

Option B required trust, a Product Owner with authority and a supplier willing to commit to effort and not a specification. Both sides gave up something: the buyer certainty about the exact list, and the supplier the ability to hide behind it.

Risks for each side

For the buyer. Not knowing what it will receive can be uncomfortable. Mitigations: a ranked list, forecasts as ranges, early working increments and the right to stop.

For the supplier. Underestimating the effort, or taking a price that does not allow for learning. Mitigations: pricing the team and time, not the specification; a checkpoint; shared risk for unexpected changes.

For both. A contract that uses agile vocabulary but behaves like a fixed specification, with Sprints that are fake and a backlog that cannot change. The ritual is there and the flexibility is not. Check with the question: what happens when we learn something that changes the plan? If the answer is "a change request," it is not an agile contract.

Governance and law

Contracts are legal documents, and procurement rules often assume fixed specifications. Public bodies in particular may need to justify the choice of model. The advice in this post is about the shape of the arrangement, not legal advice, and parties should involve their lawyers and procurement staff early, and explain how the framework produces evidence of progress.

How to practise it

For a contract you know, write which of the three variables is fixed and which is free, and how a change is handled. If a change needs a new document, ask what a lighter rule would be. In the simulator the Sponsor presses for scope, and your handling of the trade-off between scope, time and money is part of what is scored.