Agile contracts: deadlines, acceptance and liability in IT projects

An agile contract records a collaboration in which the end result is not fixed in advance, so it must regulate who sets priorities, when a sprint result is accepted and whether delivery dates are binding. Under Dutch law, a delivery date in an agile project is not automatically a strict deadline: the court looks at the contract, the working method and how the parties actually cooperated, and even a missed strict deadline does not always justify rescission.

In agile development, the parties work in short sprints and adjust the product as the project progresses. This article explains how to qualify the supplier’s obligation, how to structure the contract, what recent case law says about deadlines, and what clients and suppliers should check.

Why does agile working need a different contract?

Because the result is a moving target. In a traditional IT project, the parties fix a functional and technical design and the supplier promises to deliver it on a set date; in agile development, each sprint delivers a working part and the client adjusts course on the basis of demonstrations.

The contract must therefore settle four subjects that a traditional specification answers by itself:

• who determines the specifications and priorities: the product owner on the client’s side;
• how changes are processed in the backlog (the prioritised list of functionality still to be built), the planning and the price;
• when a part counts as finished, based on a definition of done and measurable acceptance criteria;
• whether agreed delivery dates are strict or indicative.

Agile working is hard to combine with a public tender in which the scope is fully fixed in advance. A contracting authority that wants agile development should leave room in the tender documents for a framework agreement with flexibly defined call-off assignments.

Is it a best-efforts or a results obligation?

In agile projects, the supplier’s obligation is often qualified as a best-efforts obligation (inspanningsverbintenis), because no fixed end result has been agreed. Under a results obligation (resultaatsverbintenis), the supplier promises a specifically described result.

The label in the contract is not decisive: the court looks at the content of the arrangements and how the parties actually worked. Under a results obligation, the question is whether the result was delivered; under a best-efforts obligation, whether the supplier showed the care of a reasonably competent and reasonably acting IT professional.

Article 6:74(1) of the Dutch Civil Code (BW) is the basis for damages for an attributable failure to perform, but it does not say when there is a failure; that depends on the qualification of the obligation. Under Article 6:248(1) BW, a contract also has the consequences that follow from reasonableness and fairness, which leaves room to take the agile nature of the collaboration into account.

How do you structure an agile contract?

Usually in two layers. A framework agreement sets the general rules: applicable terms, liability, confidentiality, intellectual property and the way of cooperating. For each assignment or release, an implementing agreement sets the scope, planning, team, price and acceptance criteria.

Concrete, measurable acceptance criteria per sprint matter more than the label of the obligation. Without them, there is nothing to test the result against, and disputes about whether a sprint succeeded arise quickly. Include a definition of done that covers not only functionality but also code quality, documentation and transferability.

Early termination deserves more attention than in a traditional contract, because an agile project has no fixed end point. Agree when each party may stop, what happens to delivered components and source code, and how the work is handed over to another supplier.

Standard IT terms, such as the NLdigital Terms, regulate agile aspects only to a limited extent. Check which edition applies and record the agile arrangements in the implementing agreement.

What does case law say about deadlines?

There is no general rule that a date in an agile project is never strict. Two recent judgments show how the court weighs the contract and the cooperation.

District Court of Midden-Nederland, 2023: strict deadline, but no rescission

In a judgment with ECLI:NL:RBMNE:2023:5936, software for a weighing system was developed using scrum, with an agreed lead time of about 24 weeks and later fixed calendar dates. The court held that these dates were strict deadlines, so the supplier was in default without a notice of default when they passed.

The client’s rescission nevertheless failed. Given the agile nature of the project, the shared responsibility of both parties and the fact that only one work block remained, the failure did not justify rescission under Article 6:265 BW. The claims for repayment and damages were dismissed.

District Court of Amsterdam, 22 April 2026: indicative dates

In ECLI:NL:RBAMS:2026:3930, a client claimed that the developer had delivered a new app late, exceeded the budget and maintained existing apps poorly. The quotation used two-week scrum sprints and an indicative launch date.

The court found no strict deadlines: the launch date and sprint planning were indicative, and the scrum approach required close cooperation. Without a strict deadline, the client needed a valid notice of default, and its notices did not put the developer in default. All claims were dismissed.

The lesson: if you want a date to be strict, state that expressly in the contract. A date in a quotation or e-mail is usually not enough.

What should you check as a client?

• Who is your product owner, and does that person have a mandate to change the backlog on your behalf?
• Are acceptance criteria and a definition of done recorded for each sprint or release?
• Does the contract state expressly which dates are strict deadlines?
• Within which period must you test and respond to a delivery, and what happens if you do not?
• When do you receive access to the source code and documentation?
• What is handed over on early termination, and at what price?

What should you check as a supplier?

• Is it clear that dates in quotations and planning are indicative, unless agreed otherwise?
• Do you record decisions of the product owner and changes in the backlog in writing?
• Do you record when the client does not provide input, test capacity or decisions on time? This can amount to creditor’s default (Article 6:58 BW).
• Is the payment basis clear: per sprint, per hour, per function point or per result?
• Have you limited your liability and excluded consequential loss in the framework agreement?

What can we do for you with agile contracts?

Our IT lawyers assist IT suppliers and clients with agile projects. We can:

• draft or review a framework agreement and implementing agreements for an agile project;
• formulate acceptance criteria, a definition of done and clear deadline clauses;
• draft an exit arrangement for early termination and transfer to another supplier;
• assess whether a supplier is in default and whether rescission is possible;
• draft a notice of default or a response to one, and conduct proceedings about delay or termination.

Read more about what an IT lawyer does.

Summary

• An agile contract usually consists of a framework agreement and implementing agreements per assignment.
• The supplier’s obligation is often a best-efforts obligation; the label in the contract is not decisive.
• Measurable acceptance criteria and a definition of done prevent disputes about whether a sprint succeeded.
• Whether a delivery date is a strict deadline depends on the contract and the cooperation, so state it expressly; even a missed strict deadline does not automatically justify rescission (ECLI:NL:RBMNE:2023:5936).
• Regulate early termination, source code and handover to another supplier in advance.

Frequently asked questions