Agile software development sits awkwardly with contracts in which the end result, the scope of the assignment and the delivery date are fixed in advance. In an agile project the parties work in short sprints, defined periods of work, and the content of the product is adjusted as the project progresses.
That offers flexibility, but it also raises legal questions. Who sets the priorities? When is a sprint result accepted? And when does a missed delivery date result in default? This article sets out how parties can answer these questions contractually.
By an agile contract we mean, in what follows, the set of arrangements by which the parties record an agile collaboration. In practice that collaboration takes the form of a framework agreement with separate implementing agreements for each assignment.
Agile working and contracting
In a traditional IT project the parties settle a functional and technical design in advance. The supplier then undertakes to deliver that result at a given moment. In agile development that fixed destination is deliberately absent: the result is a moving objective.
Each sprint delivers a working, usable part of the software. On the basis of demonstrations and user experience the client adjusts course. Where a traditional contract records where the project ends, in agile working that remains open.
Parties must therefore settle contractually what a traditional project usually already shows from the specification. Four subjects stand out:
- who determines the specifications, that is, who fulfils the product owner role (the person setting priorities on the client's behalf);
- how changes are processed into the backlog (the prioritised list of functionality still to be built), the planning and the price;
- when a component counts as complete, based on a definition of done (the agreed criteria for a finished result) and acceptance criteria (the requirements against which a delivery is tested);
- whether agreed delivery dates are strict or indicative.
One practical consequence: agile working is hard to combine with a tender in which the scope of the assignment is fixed entirely in advance. A party subject to procurement rules that nonetheless wants agile development is well advised to create room in the tender documents for a framework agreement with flexibly defined implementing assignments.
Best-efforts or results obligation?
Under a best-efforts obligation the supplier does not guarantee a particular result. It undertakes to apply the care that may be expected of a reasonably competent and reasonably acting professional. Under a results obligation it does commit to a specifically described result.
The label in the contract is not decisive. Even where a contract refers to a results obligation, the court may find, on the basis of the substance of the arrangements and their context, that it is in fact a best-efforts obligation, and vice versa. How the parties actually work together therefore weighs at least as heavily as the wording chosen.
The distinction matters in practice because under a results obligation the agreed result is central, whereas under a best-efforts obligation it must be assessed whether the supplier applied the required effort. That difference determines what the parties argue about in a dispute and what they must show.
Two statutory provisions recur here. Article 6:74(1) of the Dutch Civil Code provides the basis for damages for an attributable failure to perform. It does not, however, say when there is a failure; that depends on the qualification of the obligation and the content of the arrangements. Article 6:248 provides that a contract also has the consequences flowing from reasonableness and fairness. That leaves room to take the nature of an agile collaboration into account when interpreting the parties' obligations.
The contractual basis: framework and implementing agreements
In practice the agile collaboration is recorded in layers. A framework agreement governs the general framework: applicable terms, liability, confidentiality and the manner of cooperation.
For each assignment the parties conclude an implementing agreement, setting out the scope, planning, team composition, price and acceptance criteria for that part. The legal relationship thus stays stable while the substance can move with each sprint or release.
Without clear acceptance criteria there is no record of what the result must be tested against. Disputes about whether the sprint succeeded then arise more readily. Concrete, measurable acceptance criteria per sprint are therefore more important than the label the parties attach to the obligation.
One subject deserving more attention in agile contracts than in traditional IT contracts is early termination. Because an agile project is a series of consecutive sprints without a fixed end point, the contract must govern when a party may stop, what happens to components and source code already delivered, and how transfer to another supplier proceeds.
General terms and conditions also matter here. The NLdigital Terms 2025 succeed the 2020 edition, adding chapters on compliance, cybersecurity, data sharing, artificial intelligence and online platforms, among others. The 2020 terms remain in force where the parties agreed them, so check which version applies to your contract. They address the specific agile aspects only to a limited extent; those must be settled by the parties in the implementing agreement.
Case law on deadlines and cooperation
The case law shows no general rule that an agile delivery date can never be strict. The qualification depends on the content of the contract, the working method chosen and the parties' actual cooperation. Three cases illustrate this.
District Court of Midden-Nederland, 26 July 2023 (ECLI:NL:RBMNE:2023:5936). Supplier IPS developed weighing scale software using scrum for client Synergy. The contract referred to a lead time of about 24 weeks. That was not met; a new deadline was postponed and missed again. When, in mid-December 2020, nine of the ten agreed weekly blocks had been delivered, Synergy rescinded the contract. The court held that the lead time promised did count as a strict deadline, so that default had arisen. The rescission did not stand, however: given the nature of the collaboration, in which new arrangements are made when deadlines are missed, and given that the project was nearly complete, that default did not justify rescission. Practical significance: even within an agile collaboration a promised lead time can be strict, but default does not automatically make a rescission stick.
District Court of Amsterdam, 22 April 2026 (ECLI:NL:RBAMS:2026:3930). A client alleged that developer DTT had delivered a new mobile app late, exceeded the budgeted costs and performed maintenance on existing apps inadequately. The court dismissed all claims. There were no strict deadlines: the delivery date named in the quotation and in the correspondence had to be seen as a best-efforts obligation within an agile or scrum working method, in which flexibility and evolving insight are central. Practical significance: a party wanting a date to be strict must record that expressly; a date in a quotation is not enough.
Amsterdam Court of Appeal, in the case between On Air and Triple IT. The parties had agreed to work agile or scrum without defining end results. In that context the obligation amounts to little more than making competent developers available who apply themselves in accordance with the design and with the duty of care of a diligent contractor. If what is delivered does not comply, the efforts to make it comply are in principle additional work. That may be different where the supplier has not kept to the arrangements or its duty of care, but the burden of proving that rests on the client. The mere fact that the end product's performance does not meet the client's wishes is therefore insufficient to establish a failure. In these proceedings the court also appointed an IT expert to explain terms such as scrum master, sprint and done. Practical significance: where defined end results are absent, remedial work readily falls to the client's account.
In assessing a claim for rescission the court may therefore weigh what role each party played in the delay and the conduct of the project. A party that does not want to depend on that weighing in an individual case must itself record when a deadline is strict and when early termination is possible.
Eight points to address in the contract
Work through the following points when drafting an agile contract. For each subject, formulate the answer to the accompanying question.
- Scope: which functionality falls within the sprint, and what is expressly outside it?
- Prioritisation: who may change the backlog, and does that person have a mandate to do so on the client's behalf?
- Acceptance: within what period must the client test and respond, and what applies if it does not?
- Deadlines: is the date named indicative or strict, and does the contract say so in as many words?
- Price: is payment per sprint, per function point, per hours deployed or per result?
- Ownership and use: at what moment does the client obtain access to source code and documentation?
- Termination: what is transferred on early termination, and against what payment?
- Continuity: can another supplier continue the work, and what documentation and code transferability does that require?
Also include a definition of done that is not only functional but sets requirements as to quality, documentation and transferability of the code. Otherwise a dispute about whether the delivered work is usable will still arise on termination.
Conclusion
Agile working offers flexibility, but calls for a contract that differs fundamentally from the traditional model. The distinction between best-efforts and results obligations, clear acceptance criteria and an arrangement for early termination are decisive. The cases discussed show that the outcome depends heavily on the specific arrangements and the actual cooperation. A contract addressing these points aligns better with how the parties really work and reduces the risk of disputes.
Law & More assists IT suppliers and clients in drafting, reviewing and negotiating framework and implementing agreements, and advises on the qualification of obligations, acceptance criteria and exit arrangements. Are you facing a dispute about delay, results or termination of an agile project? Please feel free to contact us for tailored advice.
Frequently asked questions
Below we answer the questions we are asked most often on this subject.
What is an agile contract?
The set of arrangements by which parties record an agile collaboration. In practice it consists of a framework agreement setting the general framework, with an implementing agreement for each assignment covering the scope, planning, price and acceptance criteria for that part.
Is a delivery date in an agile project a strict deadline?
Not automatically. There is no general rule; it depends on the contract, the working method and the actual cooperation. If you want a date to be strict, record that in as many words. A date in a quotation has been held insufficient.
What is the difference between a best-efforts and a results obligation?
Under a results obligation the agreed result is central. Under a best-efforts obligation it must be assessed whether the supplier applied the required effort. That difference determines what the parties argue about in a dispute.
Is the label in the contract decisive?
No. Even where the contract refers to a results obligation, the court may find on the basis of the substance and context that it is in fact a best-efforts obligation, and vice versa. How the parties actually work weighs at least as heavily.
Who may change the backlog?
The person fulfilling the product owner role. Record who that is and whether they have a mandate to do so on the client's behalf. Without that arrangement, disputes arise about who is responsible for changes in priorities.
Why do acceptance criteria matter so much?
Without clear acceptance criteria there is no record of what the result must be tested against. Disputes about whether the sprint succeeded then arise more readily. In practice they matter more than the label attached to the obligation.
Who pays for remedial work if the delivery does not comply?
Where no end results have been defined, the efforts to meet the client's wishes fall in principle to the client's account as additional work. That is different where the supplier has not kept to the arrangements or its duty of care, but the burden of proving that lies with the client.
How is payment arranged in agile working?
Tying payment to a single fixed delivery moment sits poorly with a method without a fixed end result. Common alternatives are payment per sprint, per function point or per hours deployed. Record the chosen basis expressly.
Can I combine agile working with a public tender?
That calls for an adapted approach, because a tender with a fully fixed scope presupposes a result known in advance. Create room in the tender documents for a framework agreement with flexibly defined implementing assignments.
What should I arrange about early termination?
On what conditions a party may stop, what happens to components and source code already delivered, against what payment transfer takes place, and what another supplier needs in order to continue the work.
Do the NLdigital Terms 2025 provide enough guidance?
Only to a limited extent. They succeed the 2020 edition and add chapters on compliance, cybersecurity, data sharing, artificial intelligence and online platforms, among others, but do not address the specific agile aspects. The 2020 terms remain in force where they were agreed. Those you must settle yourself in the implementing agreement.
Do you have a dispute with an IT supplier, or would you like an IT contract reviewed? Our IT lawyers are happy to help.
