MKB Juristen drafts custom legal documents
It is best not to cobble together or copy important contracts, terms and conditions, and other legal documents yourself. We help entrepreneurs on a budget with customized legal solutions, clear costs upfront, and practical explanations.
- Custom contracts, terms and conditions, and legal documents
- Budget-friendly and clear about the costs upfront
- Request a free consultation or a no-obligation quote
What is an agile software development agreement? It is a contract for software development using an agile methodology (Scrum, sprints), where the scope is deliberately not fixed in advance. Instead of a single fixed end result at a fixed price, you agree on a working method, budget and timeframes, and acceptance per sprint. The client makes adjustments along the way based on what is delivered. This suits projects where requirements become even stricter during development, but it does require different agreements than a classic fixed-price contract.
The short answer
- Methodology instead of end product. You define Scrum, sprints, and collaboration, not a single delimited specification.
- No fixed scope. The backlog and priorities may change per sprint.
- Budget and timeframes. Often an hourly rate or team rate per sprint, within an agreed maximum.
- Acceptance per sprint. The client approves delivered work sprint by sprint.
- IP, additional work, and exit. Who receives the rights, how do you handle overruns, and how do you terminate the agreement midway.
What exactly is an agile software development agreement?
In a classic development contract, you describe in detail in advance what the software must do, at what price, and by when. The supplier builds it and delivers it. If the software does not work as described, that is their problem.
An agile software development agreement reverses this. The parties acknowledge that not all requirements are known in advance. Working software is delivered, reviewed, and adjusted in short cycles (sprints of usually one to four weeks). The contract therefore primarily establishes the ground rules for that collaboration: roles, sprint length, how the backlog is prioritized, and how to accept and pay step-by-step.
Scrum and sprints in the contract
Scrum is the most widely used agile framework. The key elements are reflected in the agreement:
- Product owner. Usually someone from the client who sets priorities and manages the backlog. Contractually important: this person must be available and have decision-making authority.
- Sprints. Fixed periods during which the team takes on a defined amount of work. Determine the sprint length and the number of planned sprints.
- Backlog. The priority list of desired functionality. This may change — that is exactly the intention.
- Sprint review. At the end of each sprint, the client reviews what has been built.
No fixed scope, but frameworks
The most essential difference compared to a standard contract: there is no rigid scope. This makes some clients nervous, because how do you know where you stand then? The answer lies in the framework.
- Budget framework. A maximum amount or a number of sprints at a fixed rate. As soon as the budget runs out, the client decides whether to extend.
- Timeframe. An indicative end date or a number of sprints, with the agreement that the scope will be adjusted if time is a constraint (not quality).
- Minimum requirements. Sometimes a list of functionality that absolutely must be included — a minimum viable product — so that the client is not left with an unfinished product.
This way, you maintain the flexibility of agile, but without signing a blank check.
Acceptance per sprint
With a fixed-price contract, you accept the entire product once at the end. With agile, you approve per sprint. This reduces the risk: you discover problems early, rather than waiting months.
Stipulate in the contract what “accepted” means. Usually: the delivered functionality meets the acceptance criteria agreed upon in advance per sprint (the “definition of done”). Also establish a response period — for example, that work is considered accepted if the client does not respond within ten working days. Without such a period, a project can remain in limbo indefinitely.
IP, additional work and exit
Three issues that often go wrong when the contract is too thin:
- Intellectual Property (IP). Copyright on custom software originates with the creator (the supplier), not automatically with the client. If the client wishes to acquire the rights, this must be explicitly transferred in the contract. Also pay attention to open-source components and existing building blocks from the supplier, for which often only a license is granted.
- Additional work. Because the scope changes, the line between “ordinary” adjustments and genuine additional work is difficult to define. Agree that work within the budget framework continues as normal, and that sprint extensions or additional budget are confirmed in writing in advance.
- Exit. Because you can terminate the project midway, an exit arrangement is crucial: notice period, completion of the current sprint, transfer of the source code and documentation, and payment for work delivered up to that point.
Suitable for which projects?
Agile is suitable for projects where requirements become clearer along the way: a new platform, an app whose usage still needs to crystallize, or software that adapts to a changing market. For a tightly defined task with fixed requirements — a simple integration or a standard website — a fixed-price contract is often simpler.
Example: An SME wholesaler wants an order dashboard for customers. The precise features depend on how customers will use it. With an agile agreement, the supplier first builds the ordering process, the wholesaler reviews it, and then determines whether reporting or inventory insight is worth the next sprint. The budget is capped at eight sprints.
Honest recommendation
An agile software development agreement is the right choice if you need flexibility and are willing to actively contribute as the client. Ensure that budget and timeframes, sprint acceptance, IP transfer, and an exit strategy are in writing—precisely because the scope is deliberately left open.
If you have a small, tightly defined project with fixed requirements, you do not need a lawyer or an agile contract; a simple fixed-price model will suffice. If you have doubts about intellectual property, additional work, or the exit, or if a substantial budget is involved, have the contract reviewed once. This pays for itself as soon as a difference of opinion arises regarding what has been agreed.
Want to know more or have one drafted? View the agile software development agreement, read how to draft such an agile software development agreement and what it costs to have one drafted.
Frequently Asked Questions
A contract for software development using an agile methodology (Scrum, sprints), where the scope is not fixed in advance. You define the methodology, budget and timeframes, and acceptance per sprint, instead of a single fixed end product at a fixed price.
With a fixed-price contract, the scope, price, and end date are set in advance, and you accept the entire product once. With agile, the scope evolves, you pay per sprint or hour within a budget framework, and you accept sprint by sprint. Agile is suitable when requirements become even stricter during development.
At the end of each sprint, the client assesses the delivered functionality based on pre-agreed acceptance criteria (definition of done). Establish a response time, for example, approval if no response is received within ten working days, so that the project does not stall.
Copyright on custom software originates with the creator, i.e., the supplier. If the client wishes to acquire the rights, this must be explicitly transferred in the contract. For open-source and existing building blocks from the supplier, the client usually receives only a license.
By agreeing on frameworks: a maximum budget or a fixed number of sprints, an indicative timeframe where the scope (not the quality) is sacrificed if time is tight, and optionally a list of minimum functionality. This way, you maintain flexibility without unlimited costs.
Yes, provided the contract includes an exit arrangement: notice period, completion of the current sprint, transfer of source code and documentation, and payment for the work delivered. Precisely because you work step by step with agile, stopping is easier than with a fixed-price contract, provided it is properly arranged.
For projects where requirements become clearer along the way, such as a new platform or an app whose usage still needs to crystallize. For a tightly defined, small project with fixed requirements, a simple fixed-price contract is often more practical.
