Agile Contracts: How to Structure Agreements for Scrum Projects

The relationship between agile methods and traditional contracts is genuinely uncomfortable. A fixed-scope, fixed-price contract assumes that requirements can be fully specified in advance, that the scope will not change materially during delivery, and that the supplier can estimate the total effort with enough precision to accept all the financial risk of scope ambiguity. Scrum assumes none of these things. It treats requirements as emerging, accepts that the most valuable features are often discovered during delivery rather than specified before it, and uses the Sprint as a cadence for delivering and reviewing working software rather than a mechanism for managing contractual milestones. The result is that organisations often try to run agile projects inside traditional contract structures — and end up with the worst of both worlds: a fixed-scope contract that does not reflect what actually gets built, combined with a delivery approach that makes it difficult to manage scope changes formally.

Contract models that work with agile

There is no single contract structure that works for all agile engagements, but three models have demonstrated consistent utility.

1. Time-and-materials with a cap. The client pays for actual time and materials consumed, up to a maximum ceiling. This gives the supplier a commercial incentive to work efficiently and gives the client budget certainty, while preserving the flexibility to adjust scope as the project evolves. The cap needs to be set with enough headroom that it does not become a de-facto fixed price; a cap that is too tight reverts to the same scope-fixing pressure as a fixed-price contract. Governance requires the client to actively manage the backlog and track burn rate against the cap throughout delivery.

2. Fixed-price iterative (Sprints as milestones). The contract defines a fixed price for a defined number of Sprints, with a specified team composition and Sprint length. Scope is prioritised at the Sprint level, not fixed across the whole engagement. Payment milestones align with Sprint reviews, where the client accepts the working software delivered in that Sprint. This model works when the client trusts the team's throughput and is willing to actively manage priorities rather than hand off a requirements document and expect delivery.

3. Money-for-nothing / change-for-free. Popularised by Jeff Sutherland, this model allows the client to terminate the contract early (money-for-nothing) if the delivered software already meets their needs, without paying for the remaining contracted time. In exchange, the client can change scope items of equal or lesser size (change-for-free) at any point during delivery. The commercial logic is that early termination saves the supplier nothing in a time-and-materials world — the clauses are designed to align incentives around delivering value rather than burning hours.

Key contract clauses for agile engagements

Regardless of the model chosen, certain clauses are essential for agile contracts to function properly.

1. Product Owner access. The contract should specify that a qualified Product Owner will be available to the team for a defined minimum number of hours per Sprint — typically at least 20 per cent of the Sprint duration for a full-time team. An unavailable Product Owner is the single most common cause of agile project failure; making the commitment contractual creates accountability on the client side.

2. Definition of Done. The contract should include or incorporate by reference the Definition of Done agreed between the team and the client. This is the quality standard against which delivered software is accepted. Without a contractual Definition of Done, acceptance disputes have no objective basis for resolution.

3. Sprint review attendance. The client's obligation to attend Sprint reviews should be stated. A client who does not attend Sprint reviews cannot accept software, cannot provide the feedback that drives backlog refinement, and — if payment milestones are tied to Sprint reviews — creates payment ambiguity through their own absence. The clause should also specify what happens if the client fails to attend a Sprint review: typically, software is deemed accepted after a defined waiting period.

4. Scope change process. Even in a flexible agile contract, changes to the overall engagement — new epics not in the original backlog, material changes to the team composition, extensions beyond the contracted period — need a defined change process. The process should be lightweight: a written change request, an estimate of effort, a commercial adjustment (if applicable), and a sign-off from authorised representatives on both sides. The absence of a change process does not mean changes do not happen; it means they happen informally and create disputes later.

What to avoid

Fixed scope with an agile delivery method is the most common trap. If the contract specifies every user story and the client can claim breach for any story not delivered as written, the team cannot exercise the backlog flexibility that makes Scrum valuable. The delivery method becomes a thin veneer over waterfall requirements management. A related trap is using Sprints as reporting periods rather than delivery cadences: producing a Sprint plan and a Sprint review for contractual purposes while actually building to a fixed waterfall design. This creates the overhead of both methods without the benefits of either.

Intellectual property provisions also deserve attention in agile contracts. In a traditional engagement, IP transfer is straightforward: the supplier delivers a defined set of deliverables and IP transfers on acceptance. In an agile engagement where software is delivered incrementally across many Sprints, it is important to specify when IP transfers — at each Sprint review, at contract completion, or at final payment. A supplier who retains IP until final payment and terminates mid-project leaves the client with partially built software they may not legally own. Interim IP transfer, even if it creates administrative complexity, protects the client's investment in a way that a traditional IP clause does not.

If your organisation is struggling to structure contracts that enable agile delivery without creating legal and commercial risk, XNM's program and project delivery advisory can help you design contract frameworks that align with the way your teams actually work — and protect both parties when things do not go as planned.