Agile fixed-price contracts: how to fix the budget and still let the scope evolve

An agile fixed-price contract locks three things (the price, the deadline and the business goal) and leaves the detail of the scope open. Features form a prioritised backlog, estimated in comparable sizes and delivered in increments. The client can replace a feature that has not been started with another of the same size, without a change request and without extra cost. The budget holds, and the software you receive reflects what you learned along the way rather than what you imagined on day one.

This article explains why fixed price and agile look incompatible, which mechanisms reconcile them, what to write in the statement of work, and when the model is the wrong choice.

Why fixed price and agile seem to clash

A traditional fixed-price contract freezes everything: a detailed specification, a price, a date. The supplier commits to the result and carries the overrun risk. It is reassuring but rigid. Every new idea becomes a change request, and teams sometimes deliver exactly what was written while the actual need has moved on.

Agile methods start from the opposite assumption. The Agile Manifesto of 2001 values "customer collaboration over contract negotiation" and "responding to change over following a plan". The Scrum Guide describes a product backlog as an ordered list that evolves continuously. None of that looks like a fixed-price contract.

In practice, many companies resolve the tension by buying agile on a time and materials (T&M) basis: sprints billed by the day. They gain flexibility but take back the entire overrun risk, as our comparison of fixed price and time and materials explains. Agile fixed price tries to keep the benefits of both.

What is fixed and what moves

Every project has three linked variables: scope, cost and time, the classic "iron triangle". Traditional fixed price locks all three, leaving no margin when reality departs from the plan. Agile fixed price locks two and turns the third into a variable that is actively managed.

The goal stays fixed, and that matters. "Let field technicians log their jobs on site and trigger invoicing" is a goal. The list of screens needed to get there can change; the goal cannot.

The six mechanisms that make it work

1. A visible scope before anyone signs

You cannot fix a price on a vague need, agile or not. Before signing, scope has to be made concrete: the main screens, the user journeys, the essential business rules. A visual prototype is the most effective tool for this, because it exposes misunderstandings before they cost money. Our guide to software project scoping covers this step in detail.

2. A backlog estimated in comparable sizes

The initial scope is a list of features, each written from the user's point of view and estimated in relative size (small, medium, large, or story points). Precision on each estimate matters less than consistency between them: that consistency is what makes swaps fair. For estimation methods, see how to estimate a software project.

3. Explicit prioritisation

Every feature is ranked. MoSCoW (must have, should have, could have, won't have this time) is the most widely used scheme. Development follows that order. Direct consequence: if the budget runs short, whatever is left out is, by construction, the least important.

4. The like-for-like swap rule

This is the heart of the model. The contract states that a feature not yet started can be removed and replaced by another of equivalent estimated size, with no change to price or date. A few rules keep swaps honest:

• swaps only apply to work that has not started; finished work stays finished;
• the new feature is sized with the same method as the others and agreed by both parties;
• a net addition, with nothing removed, is not a swap: it goes through a change request or a separately priced phase;
• every swap is recorded, with its date, in a shared change log.

5. Incremental delivery, with a demo and acceptance testing

The software is delivered in increments, every two to four weeks for example, each one demonstrated and then accepted. Those moments are when the client learns what they really want, and when swaps are decided. Increment-level user acceptance testing also avoids a single acceptance phase at the end, where every risk piles up. Our UAT checklist applies to each increment.

6. A contingency and an early exit

Part of the budget can be set aside from the start for discoveries: forgotten business cases, adjustments after a demo. It is spent by joint decision, never by default. An early termination clause also lets the client stop at the end of any increment, keeping what has been delivered, if the software already does the job or the need has changed. Jeff Sutherland, co-creator of Scrum, presented this pairing at the Agile 2008 conference as "Money for Nothing and Your Change for Free": changes are free when the total work stays the same, and stopping early is planned in advance, in his version against a termination fee agreed up front.

A worked swap

A fictional example. A field services company commissions a job management application on an agile fixed-price basis. The initial backlog has around thirty estimated features. At the demo of the second increment, the technicians explain they will never use the weekly mobile schedule: they receive their route the evening before, and what they really need is to photograph the site for the job report.

The "weekly mobile schedule" feature (medium, not started) is removed. "Photos attached to the job report" (estimated medium) takes its place at the same priority. Price and end date do not move. The swap is entered in the change log and signed off by the client's product owner.

Six months later, the software looks more like the technicians' real work than like the original specification. That is exactly the point.

What to write in the contract

An agile fixed-price deal only holds if its rules are written down, usually in the statement of work (SOW) attached to the master agreement. At a minimum:

• the business goal, in one or two measurable sentences;
• the initial backlog, as an annex, with the size and priority of every feature;
• the swap rule: what can be swapped, how size is estimated, who approves, how it is recorded;
• the increment cadence, with the demo and acceptance test for each;
• the definition of done: tested, documented, deployed to the acceptance environment;
• the client's role: who decides, within what timeframe, with what authority;
• early termination: at which points, with which deliverables, and with intellectual property rights defined case by case in the contract;
• net additions: a change request or extra phase, priced before work starts.

These terms come on top of those found in any development agreement, covered in our article on software development contract clauses.

What it asks of the client

Agile fixed price asks more of the client than a traditional fixed-price project. You need:

• a product owner with the authority to decide without convening a committee for every question;
• time at every increment for the demo, testing and trade-offs;
• real users at demos, not only management;
• the discipline to prioritise: saying one feature matters less than another is harder than it sounds.

Without these, agility turns into permanent vagueness, and the fixed price into a source of friction.

Pitfalls to avoid

Agile as an excuse not to scope. "We will figure it out in the sprint" is not a method. Without a visible scope, a supplier cannot commit to a price, or does so with a very large risk margin.

Fixed price that hides T&M. A contract that fixes a number of sprints but no goal and no backlog is not fixed price: it is capped T&M. The client pays for the sprints whatever the outcome.

Swaps that grow. A feature "of the same size" that in reality contains three will derail the project. Shared estimation and the change log exist to prevent exactly that.

A backlog that never empties. Every demo generates ideas. They go into a separate list for the next release, unless they replace something through a swap.

When it is the wrong model

Agile fixed price suits business software whose goal is clear but whose details will emerge through use. It suits less well a product still looking for its market, where the goal itself may change within weeks. In that case, short phases priced one at a time work better, starting with a minimal first version. Our article on what to build first in an MVP helps draw that line.

How we work

LPR Studio does not sell time and materials. Our fixed-price projects rest on a scope made visible before any commitment: we first build a free visual prototype, presented on a video call within 5 business days. Once approved, it becomes the basis for the fixed price, then for the split into increments demonstrated throughout the project. If you would rather not pay for development up front, our subscription model covers hosting, maintenance and changes for a monthly fee, and priorities are traded off the same way, as the software is used.