Agile delivery inside a fixed-scope contract

A fixed-price contract fixes three things in most people's minds: what is built, when it lands, and what it costs. Iterative delivery assumes the first of those will change as you learn. That is the whole conflict, and it lives entirely in the first item.

Fix the outcome instead of the feature list and the conflict mostly dissolves. "A booking flow that lets a returning customer rebook in under three steps, live by 30 September, for the agreed fee" is a fixed commitment. It is testable, it is fundable, and it does not specify which screens exist. Notice that the client can tell whether you delivered it.

This is not a drafting trick. It is a claim about what clients actually buy. Almost nobody wants seventeen specific features; they want a business result and the feature list is their proxy for it. Trading the proxy for the thing itself is a better deal for both parties, and the only reason it is uncommon is that outcomes are harder to write than lists.

The last row is the one clients and agencies both try to flex under pressure, and it is the one that must not move. Everything else in the table can be traded at a boundary. Lowering the quality bar to hit a date converts a schedule problem into a defect problem, and the defect problem arrives after the invoice, when you have no leverage left.

The order of delivery row is quietly the most valuable thing you can offer a client on a fixed-price engagement. They give up the right to add unlimited scope. In exchange they get the right to decide, repeatedly, what gets built first. Most clients value that far more than they expect to, because it converts a single up-front bet into a series of small ones.

In a waterfall contract, change happens through a formal request that everybody experiences as an escalation. In this arrangement, change happens at a scheduled point that everybody expects, which removes almost all of the friction.

Atlassian's framing of the sprint review is useful here because it describes exactly the event a fixed-price contract needs: the team demonstrates completed work to stakeholders, discusses what was accomplished, what remains unfinished, and any changes to the backlog, with the product owner reprioritising based on the feedback. That is a contract checkpoint that does not feel like one.

The rule that makes it commercially safe is that reprioritisation inside the fixed outcome is free and change to the outcome is not. Reordering, redesigning and substituting features of comparable size all fall inside. Adding a capability the outcome statement does not require falls outside and generates a change order.

Say the boundary out loud each time so the distinction stays live. "That is a swap, we can do it. That is an addition, here is what it costs." Said fortnightly from week one, this is unremarkable. Said for the first time in month four, it is a fight.

There is a useful distinction that gets lost when scope creep is treated as one phenomenon.

Atlassian draws it precisely: while tolerating scope creep during a sprint is bad practice, scope change within epics and releases is a natural consequence of agile development, because the product owner learns things as the work proceeds and adjusts.

That maps cleanly onto a fixed-price contract. Change inside the current iteration is disruptive and gets the swap treatment. Change between iterations, within the agreed outcome, is the mechanism working as intended and needs no ceremony at all. Change to the outcome itself is a commercial event.

Three categories, three responses, and the middle one is the one agencies most often mishandle by treating ordinary learning as a contract variation. Charging for the client changing their mind about the order of work is how you make the arrangement adversarial in a fortnight.

Fixing a date on iterative work only holds if you can show, continuously, whether it is still reachable. Otherwise the fixed date is a hope and the conversation about it happens too late.

A burn-up against the remaining outcome does this. Microsoft's guidance separates the two chart types cleanly: burndown starts from total planned work and graphs what remains, while burnup tracks work completed over time and should always trend upward. For a fixed-date contract the burn-up is the better instrument, because it shows the scope line and the progress line separately and the gap between them is the argument.

Update it at every boundary and put it in front of the client every time, including when it is fine. A chart that only appears when there is bad news becomes a signal in itself, and clients learn to dread the meeting.

Two derived numbers turn the chart into a decision. Current completion rate multiplied by the remaining boundaries tells you what will be finished by the date. The gap between that and the outcome tells you how much has to be traded away. Both are arithmetic on observed data, which is a considerably stronger position than an opinion about whether the team can catch up.

Three pieces of contract language do most of the work and none of them is unusual.

An acceptance definition tied to the outcome rather than to a deliverable list. This is what converts "is it finished" from an argument into a test. What that looks like in practice, including the parts that are commercial rather than technical, is set out in a definition of done for client work.

A change mechanism that is actually used. The clause is standard; the discipline of issuing a change note the same day is not, and its absence is where fixed-fee margin actually goes. A change control clause invoked for the first time in month five reads as a penalty. Invoked in week two for a small item, it establishes that the mechanism is routine.

A client decision window. The contract fixes a date, so client delay has to have a defined consequence or the date is unenforceable. State the response time expected at each boundary and what happens when it is missed: the team proceeds on a written assumption, and the assumption is logged as a risk. That is a fairer arrangement than the alternative, which is the agency silently absorbing the delay and losing the date anyway.

It is worth being clear about the limits rather than selling this as universal.

It does not work where the outcome cannot be stated testably. If nobody can write a sentence describing success that both parties would agree on, no contract structure will save the engagement, and the right response is to sell a paid discovery phase instead. Pricing that phase is its own problem, worked through in estimating a discovery sprint.

It does not work where the client's procurement requires a line-item deliverable schedule and will not accept an outcome statement. That is a real constraint in public sector and large enterprise buying. In that case you are writing a deliverables contract and should price the risk of the deliverables being wrong, rather than pretending the flexibility exists.

It also does not work where the client cannot supply a decision-maker at each boundary. The whole arrangement rests on someone being available to make trades on a fortnightly rhythm. Without that person the backlog is ranked by the agency, which is the arrangement everybody says they do not want.

Where it does work, it works because the commitment is honest: a fixed price for a defined result, with the path negotiated as you learn. Holding that shape across a multi-month engagement is largely a matter of somebody running the boundary discipline every time rather than when it is convenient, which is what delivery ownership as a defined role is bought to do.