Agile software development: a contract designed for sprints

A conventional contract for work assumes the result is clear at the outset: fixed scope, fixed price and final handover and acceptance of the whole. Agile development works differently. Scope develops through backlog priorities, and software is created in increments deployed throughout the project. Stretching a standard work contract over sprints produces a contract unrelated to what the parties actually do. The first dispute reveals that it protects neither side.

Where work contracts and sprints diverge

Under § 536(1) of the Commercial Code, the contractor undertakes to perform specified work and the customer to pay for it. In an agile project, however, no one can describe the final system at the outset in terms that will remain accurate until completion. What is known is the working process. The second mismatch concerns control:

Unofficial English translation:

In performing the work, the contractor acts independently and is not bound by the customer’s instructions concerning the manner of performance, unless it has expressly undertaken to follow them. — § 537(3) of Act No. 513/1991 Zb.

An agile project depends precisely on customer instructions: the product owner sets priorities every sprint. Unless the supplier expressly undertakes to follow instructions, the statutory starting point conflicts with what the customer believes it purchased.

Framework agreement and orders

Cooperation can be structured at two levels. A framework agreement sets rates, roles, ordering, acceptance, code rights, confidentiality and termination. Individual orders or sprints are placed under it, usually through a project system that also provides an evidence trail. Legally, this combines a contract for work with an unnamed contract under § 269(2) of the Commercial Code, which requires the following:

Unofficial English translation:

The parties may also conclude a contract that is not regulated as a contract type. However, if they do not sufficiently specify the subject matter of their obligations, the contract is not concluded. — § 269(2) of Act No. 513/1991 Zb.

The framework therefore concerns a precisely described process rather than a finished system: who gives instructions, who approves estimates and what a sprint produces. Fees are usually time and materials, the rate multiplied by recorded time. The law permits this because agreeing a method of determining the price is sufficient (§ 536(3)). Without an agreed rate, the usual price may apply (§ 546(1)), requiring evidence instead of a straightforward invoice. The customer is protected by a budget cap per period or order, beyond which work stops without fresh approval. The supplier is protected by a rule that recorded and accepted time remains payable if the customer stops the project early.

Incremental acceptance and the definition of done

Acceptance cannot wait until the end of an agile project. Each increment is accepted separately. The contract sets acceptance criteria, a definition of done including tests and documentation, a short response period and deemed acceptance if the customer neither responds nor reports defects within that period. Otherwise, deployed increments accumulate in legal limbo. Our guide to unsigned acceptance records and payment for work explains why silence on handover is risky even without deemed acceptance.

Defects require separate treatment. Acceptance concerns the functions delivered in that sprint, but must not release the supplier from responsibility for integration defects and regressions appearing only with later increments. Responsibility for the whole therefore runs from deployment of the last part, not the first acceptance.

Scope changes without amendments

A framework agreement allows scope changes without amending the contract itself. The backlog is a live list that the product owner adds to and reprioritises. The contract defines how an item becomes binding: supplier estimate, customer approval, then work. An agreed tolerance for overruns accompanies this. Beyond it, the supplier cannot proceed without further consent or bears the additional work itself. An escalation ladder, first project roles and then directors, resolves disagreements so one unapproved ticket does not halt the entire project.

Code, termination and repository handover

Rights to commissioned software are governed by § 91 of Act No. 185/2015 Z. z. Where development is supplied through a company, it cannot simply be assumed that the customer acquires the exercise of the author’s economic rights. This does not, however, exclude a non-exclusive licence arising from the parties’ agreement and the purpose of the contract (§§ 65 and 66). An express provision provides certainty about its scope, particularly for modifications, sublicensing and delivery of the source code. Our guide to copyright in commissioned software explains this in detail.

Timing is central to the framework: rights and access to code should pass progressively with acceptance of each increment, rather than after the final invoice. In practice, development takes place in a customer-controlled repository or code and documentation must be delivered after each sprint. Termination must be addressed in advance: termination without cause on reasonable notice, completion or settlement of ongoing orders, handover of the repository, documentation and credentials, and assistance with transition to a new supplier. If the supplier must remain on standby after deployment, price that separately. Our guide is standby payable without an intervention? explains the issue.

For both parties

A well-drafted framework protects the customer against an unlimited budget and the supplier against unapproved work. We prepare or review IT work and agile development contracts for either side, implementation agreements for deploying third-party systems, software and licence agreements covering code rights, and contracts for work for conventional fixed-scope supplies.