Drafting an Agile software development agreement: this is what should be included

Drafting an agile software development agreement means establishing the ground rules for the collaboration rather than a single, clearly defined end product. Because the scope in Scrum and sprints is deliberately left open, the contract must be particularly precise regarding the surrounding frameworks: how you work, up to what budget, how you accept per sprint, who acquires the intellectual property, how you handle additional work, and how you can terminate the project midway. Below are the standard components and the pitfalls you will want to avoid.

The short answer

1. Methodology. Scrum, sprint length, roles (product owner, team) and meeting times.
2. Budget and timeframes. Rate per sprint or hour, maximum budget, and indicative turnaround time.
3. Acceptance per sprint. Acceptance criteria, response time, and consequences of approval.
4. IP regulations. Transfer of rights, license on existing building blocks and open source.
5. Additional work and exit. When something constitutes extra, and how to terminate the contract properly.

Define working methods and roles

Start with the core: parties are developing software using an agile method. Describe which one — usually Scrum — and work out the practical arrangements.

• Sprint length. One to four weeks, with a fixed rhythm.
• Product owner. Who sets priorities and has decision-making authority? Stipulate that this person is available; an absent product owner brings an agile project to a standstill.
• Team composition. Which roles does the contractor provide, and is he allowed to replace people?
• Meeting. Sprint planning, review, and retrospective — and who attends.

Budget and timeframes

Because there is no fixed price for a fixed product, the contract stands or falls with good frameworks.

• Rate. A team rate per sprint or an hourly rate per role. State whether this is inclusive or exclusive of VAT.
• Budget ceiling. A maximum amount or a fixed number of sprints. Agree that extensions only take effect upon written instruction from the client.
• Timeframe. An indicative lead time, with the agreement that under time pressure, the scope deviates and not the quality.
• Invoicing. Usually per sprint or monthly in arrears, linked to accepted work.

Acceptance per sprint

Arrange for the client to accept per sprint, and specify concretely what that entails:

• Acceptance criteria. Agreed in advance per sprint (the definition of done).
• Response period. For example: work is considered accepted if the client does not reject it with reasons within ten working days.
• Remedial action. What happens in the event of a justified disqualification — remedial action within the next sprint, at no extra cost.

Without an acceptance process with installments, payment stalls and it remains unclear whether something is “finished”.

Intellectual property

This is the subject where most standard contracts fall short. Copyright on custom software originates with the creator — the supplier — and does not automatically transfer to the client.

• Transfer. If the client wishes to retain the rights to the custom work, the contract must explicitly transfer them in writing.
• Existing building blocks. Frameworks and libraries from the vendor are usually not transferred; a (perpetual) license applies to them.
• Open source. State that it may contain open-source components and that the associated license terms apply.
• Source code. Agree that the client receives the source code so that they do not remain dependent on a single supplier.

Additional work

In agile, the scope moves, so the question “is this additional work?” is bound to come up. Avoid discussion with a clear line:

• Work that falls within the agreed budget and timeframe is simply part of the sprints — even if the content changes.
• Increasing the budget, extra sprints, or work outside the agreed objective is considered additional work and requires prior written confirmation.
• Specify the rate at which additional work is performed.

Exit and termination

Because you work in sprints with agile, stopping midway is realistic. Handle it properly:

• Notice period. Often at the end of the current or the next sprint.
• Completion. The current sprint is finished and paid for.
• Transfer. Source code, documentation, and access to environments are being transferred.
• Payment. All work accepted up to that point will be settled; no penalty for exercising the right of exit.

Example: An SME service provider commissioned a planning tool and noticed after four sprints that priorities had shifted. Because the agreement included an exit clause with source code transfer, he was able to terminate the contract, take the delivered work with him, and continue with another party later. Without that clause, he would have been tied to the original supplier.

Honest recommendation

When drafting an agile software development agreement, the risk lies not in the technology but in the frameworks: budget, acceptance, IP, additional work, and exit. As long as you keep a clear picture of these five, you maintain the flexibility of agile without costs or rights getting out of hand.

For a small project with a trusted supplier and a limited budget, a simple order confirmation plus sound terms and conditions will often suffice; in that case, a detailed agile contract and legal counsel are unnecessary. However, if it involves a substantial budget, long-term development, or software that becomes business-critical, have the contract drafted or reviewed. IP and exit clauses are precisely the elements you only miss when things go wrong.

Read more or arrange it immediately? View the agile software development agreement, first read what an agile software development agreement is , and see what it costs to have an agile software development agreement drafted.

Frequently Asked Questions