Agile contract in het IT-recht: wat moet u vastleggen?

Gepubliceerd op 22 september 2026 · Laatst bijgewerkt op 13 oktober 2026

Een agile contract legt een IT-samenwerking in sprints vast zonder dat het eindresultaat vooraf vaststaat; regel daarin vooral wie de prioriteiten bepaalt, wanneer een sprint is geaccepteerd en of een opleverdatum fataal is. Een opleverdatum is daarbij niet automatisch fataal: wilt u dat wel, leg dat dan uitdrukkelijk vast. Een klassiek contract met een vaste opleverdatum en een vastomlijnd resultaat past vaak niet bij deze werkwijze.

Een agile-traject verloopt in sprints: korte, afgebakende werkperioden waarin u de inhoud van het product gaandeweg bijstelt. Dat geeft flexibiliteit, maar roept ook vragen op. Wie bepaalt de prioriteiten? Wanneer is een sprintresultaat geaccepteerd? En wanneer leidt een gemiste opleverdatum tot verzuim? Dit artikel bespreekt hoe u deze vragen contractueel regelt.

Met een agile-contract bedoelen wij hierna het geheel van afspraken waarmee u een agile-samenwerking vastlegt. In de praktijk krijgt dat vorm in een raamovereenkomst met daaronder afzonderlijke nadere overeenkomsten per opdracht.

Wat is het verschil met een klassiek IT-contract?

Bij een klassiek IT-project legt u vooraf een functioneel en technisch ontwerp vast. De leverancier verbindt zich vervolgens dat resultaat op een bepaald moment op te leveren. Bij agile ontwikkeling ontbreekt die vaste eindbestemming bewust: het resultaat is een veranderlijk doel.

Elke sprint levert een werkend, bruikbaar deel van de software op. Op basis van demonstraties en gebruikerservaring stuurt u vervolgens bij. Waar een klassiek contract vastlegt waar het project eindigt, blijft dat bij agile werken juist open.

Daarom regelt u contractueel wat bij een klassiek project vaak al uit het bestek blijkt. Vier onderwerpen springen eruit:

• wie de specificaties bepaalt, oftewel wie de rol van product owner vervult (degene die namens de opdrachtgever prioriteiten stelt);
• hoe wijzigingen worden verwerkt in de backlog (de geprioriteerde lijst met nog te bouwen functionaliteit), de planning en de prijs;
• wanneer een onderdeel als afgerond geldt, aan de hand van een definition of done (de afgesproken criteria voor een afgerond resultaat) en acceptatiecriteria (de eisen waaraan een oplevering wordt getoetst);
• of afgesproken opleverdata fataal zijn of indicatief.

Een praktisch gevolg: agile werken laat zich moeilijk combineren met een aanbesteding waarin de omvang van de opdracht vooraf volledig vastligt. Bent u aanbestedingsplichtig en wilt u toch agile laten ontwikkelen, maak dan in de aanbestedingsstukken ruimte voor een raamovereenkomst met flexibel in te vullen nadere opdrachten.

Is het een inspannings- of resultaatsverbintenis?

Dat hangt af van de inhoud van de afspraken en de feitelijke samenwerking, niet alleen van het label in het contract.

Bij een inspanningsverbintenis staat de leverancier niet in voor een bepaald resultaat. Hij verbindt zich in te spannen zoals van een redelijk bekwaam en redelijk handelend vakgenoot mag worden verwacht. Bij een resultaatsverbintenis verbindt hij zich juist wel tot een concreet omschreven resultaat.

Het label in het contract is niet doorslaggevend. Spreekt de overeenkomst van een resultaatsverplichting, dan kan de rechter op grond van de inhoud van de afspraken en de context toch oordelen dat feitelijk sprake is van een inspanningsverbintenis, en andersom. Hoe partijen feitelijk samenwerken weegt dus minstens zo zwaar als de gekozen bewoordingen.

Het onderscheid is praktisch relevant: bij een resultaatsverbintenis staat het overeengekomen resultaat centraal, terwijl bij een inspanningsverbintenis moet worden beoordeeld of de leverancier de vereiste inspanning heeft geleverd. Dat verschil bepaalt waarover u in een geschil discussieert en wat u moet aantonen.

Twee wetsartikelen komen hierbij terug. Artikel 6:74 lid 1 BW vormt de grondslag voor schadevergoeding wegens een toerekenbare tekortkoming; de bepaling zegt echter niet wanneer sprake is van een tekortkoming, dat hangt af van de kwalificatie van de verbintenis en de inhoud van de afspraken. Artikel 6:248 BW bepaalt dat een overeenkomst ook de gevolgen heeft die uit redelijkheid en billijkheid voortvloeien, wat ruimte biedt om de aard van een agile-samenwerking mee te wegen bij de uitleg van de verplichtingen.

Hoe legt u de agile-samenwerking contractueel vast?

In de praktijk legt u de agile-samenwerking gelaagd vast. Een raamovereenkomst regelt het algemene kader: toepasselijke voorwaarden, aansprakelijkheid, geheimhouding en de wijze van samenwerken.

Per opdracht sluit u een nadere overeenkomst, ook wel nadere opdracht genoemd, waarin de omvang, planning, teamsamenstelling, prijs en acceptatiecriteria voor dat onderdeel staan. Zo blijft de juridische verhouding stabiel terwijl de inhoud per sprint of release kan meebewegen.

Zonder duidelijke acceptatiecriteria staat niet vast waaraan het resultaat wordt getoetst. Daardoor ontstaat sneller discussie over de vraag of de sprint is geslaagd. Concrete, meetbare acceptatiecriteria per sprint zijn daarom belangrijker dan het label dat u aan de verbintenis geeft.

Regel ook de tussentijdse beëindiging: dat verdient bij agile-contracten meer aandacht dan bij klassieke IT-contracten. Omdat een agile-traject een reeks opeenvolgende sprints is zonder vast eindpunt, moet het contract regelen wanneer een partij kan stoppen, wat er gebeurt met reeds opgeleverde onderdelen en broncode, en hoe de overdracht aan een andere leverancier verloopt.

Voor de juridische inbedding zijn ook algemene voorwaarden van belang. De NLdigital Voorwaarden 2025 zijn de opvolger van de editie uit 2020 en voegen vijf nieuwe thema’s toe: compliance (onder meer de AI Act, NIS2 en de Data Act), cyberbeveiliging, datadeling, kunstmatige intelligentie en onlineplatforms. De voorwaarden uit 2020 blijven gelden wanneer u die bent overeengekomen; controleer dus welke versie op uw contract van toepassing is. De specifieke agile-aspecten voorzien beide versies slechts beperkt; die regelt u zelf in de nadere overeenkomst.

Is een opleverdatum in een agile-traject fataal?

De rechtspraak laat geen algemene regel zien dat een agile-opleverdatum nooit fataal kan zijn. De kwalificatie hangt af van de inhoud van de overeenkomst, de gekozen werkwijze en de feitelijke samenwerking tussen partijen. Drie zaken illustreren dat.

Rechtbank Midden-Nederland 2 augustus 2023 (ECLI:NL:RBMNE:2023:5936). Leverancier Industrial Problem Solvers (IPS) ontwikkelde volgens scrum software voor weegschalen voor opdrachtgever Synergy Systems. Partijen spraken een werkende applicatie af voor 1 juli 2020; die datum en volgende deadlines werden niet gehaald, waarna Synergy de overeenkomst ontbond. De rechtbank oordeelde dat IPS tekortschoot en dat verzuim was ingetreden, maar wees de ontbinding toch af: de tekortkoming was, gelet op het scrum-karakter van het project met gezamenlijke inspanning en gedeelde verantwoordelijkheid voor de vertraging, niet ernstig genoeg om ontbinding te rechtvaardigen. Betekenis voor de praktijk: ook binnen een agile-samenwerking kan een toegezegde termijn fataal zijn, maar verzuim leidt niet automatisch tot een geslaagde ontbinding.

Rechtbank Amsterdam 22 april 2026 (ECLI:NL:RBAMS:2026:3930). Een opdrachtgever verweet ontwikkelaar DTT dat een nieuwe mobiele app te laat was opgeleverd, dat de begrote kosten waren overschreden en dat het onderhoud van bestaande apps ondeugdelijk was. De rechtbank wees alle vorderingen af: de in de offerte en de communicatie genoemde opleverdatum gold als inspanningsverplichting binnen de agile/scrum-aanpak, niet als fatale termijn, en een toezegging om bepaalde werkzaamheden kosteloos uit te voeren zag alleen op die specifieke aanvullende werkzaamheden. Betekenis voor de praktijk: wilt u zeker weten dat een datum fataal is, leg dat dan uitdrukkelijk vast; een datum in een offerte is daarvoor niet genoeg.

Gerechtshof Amsterdam, in de zaak tussen On Air en Triple IT (tussenarrest ECLI:NL:GHAMS:2024:1070, deskundigenbenoeming ECLI:NL:GHAMS:2025:1814). Partijen waren agile/scrum-ontwikkeling van een front-end overeengekomen, geleverd in sprints, zonder dat het eindresultaat vooraf was gedefinieerd. On Air weigerde betaling omdat volgens haar niet aan de afgesproken voorwaarden was voldaan. Het hof benoemde een IT-deskundige om begrippen als scrum master, sprint en done toe te lichten en om te verklaren hoe branchestandaarden omgaan met tussentijdse opleveringen. Betekenis voor de praktijk: ontbreken gedefinieerde eindresultaten, dan is snel onduidelijk wat een “voltooide” oplevering juridisch betekent, en kan de rechter daarvoor deskundige voorlichting nodig achten.

Bij de beoordeling van een vordering tot ontbinding weegt de rechter dus mee welke rol beide partijen hebben gespeeld bij de vertraging en de uitvoering van het traject. Wilt u niet afhankelijk zijn van die weging in een individueel geval, leg dan zelf vast wanneer een termijn fataal is en wanneer tussentijdse beëindiging mogelijk is.

Welke punten regelt u in een agile-contract?

Loop bij het opstellen van een agile-contract de volgende punten langs. Formuleer per onderwerp het antwoord op de bijbehorende vraag.

• Omvang: welke functionaliteiten vallen binnen de sprint, en wat valt daar uitdrukkelijk buiten?
• Prioritering: wie mag de backlog wijzigen, en heeft die persoon daarvoor mandaat namens de opdrachtgever?
• Acceptatie: binnen welke termijn test en reageert de opdrachtgever, en wat geldt als hij dat niet doet?
• Termijnen: is de genoemde datum indicatief of fataal, en staat dat er met zoveel woorden?
• Prijs: rekent u af per sprint, per functiepunt, per ureninzet of per resultaat?
• Eigendom en gebruik: op welk moment krijgt de opdrachtgever toegang tot broncode en documentatie?
• Beëindiging: wat draagt u bij tussentijdse beëindiging over, en tegen welke vergoeding?
• Continuïteit: kan een andere leverancier het werk voortzetten, en wat is daarvoor nodig aan documentatie en overdraagbaarheid van de code?

Neem daarnaast een definition of done op die niet alleen functioneel is, maar ook eisen stelt aan kwaliteit, documentatie en overdraagbaarheid van de code. Anders ontstaat bij beëindiging alsnog discussie over de vraag of het opgeleverde werk bruikbaar is.

Waar let u als opdrachtgever op?

• Leg in de nadere overeenkomst vast of een opleverdatum fataal is; een datum in een offerte is daarvoor niet genoeg.
• Wijs een product owner aan met schriftelijk mandaat om de backlog te wijzigen.
• Spreek een vaste termijn af waarbinnen u een sprintoplevering test en accepteert.
• Regel toegang tot broncode en documentatie bij tussentijdse beëindiging.

Waar let u als leverancier op?

• Leg uitdrukkelijk vast dat opleverdata indicatief zijn als u geen fatale termijn wilt.
• Laat elke wijziging in de backlog met gevolgen voor planning of prijs schriftelijk bevestigen.
• Leg vast wat geldt als de opdrachtgever niet binnen de acceptatietermijn reageert.
• Controleer welke versie van de NLdigital Voorwaarden (2020 of 2025) van toepassing is.

Wat kunnen wij voor u doen bij een agile-contract?

Wij begeleiden opdrachtgevers en IT-leveranciers bij het vastleggen van een agile-samenwerking en bij geschillen daarover.

• Wij stellen de raamovereenkomst en de nadere overeenkomsten per opdracht op of beoordelen die.
• Wij formuleren meetbare acceptatiecriteria, een definition of done en een duidelijke regeling voor fatale of indicatieve termijnen.
• Wij beoordelen welke versie van de NLdigital Voorwaarden geldt en wat u daarnaast zelf moet regelen.
• Wij stellen een ingebrekestelling op of beoordelen er een, zodat duidelijk is of verzuim is ingetreden (artikel 6:82 BW).
• Wij begeleiden tussentijdse beëindiging en de overdracht van broncode aan een nieuwe leverancier.
• Wij voeren een geschil over oplevering, meerwerk of ontbinding (artikel 6:265 BW) bij de rechter.

Samengevat

• Een agile-contract bestaat doorgaans uit een raamovereenkomst met het algemene kader en per opdracht een nadere overeenkomst met omvang, planning, prijs en acceptatiecriteria.
• Een opleverdatum is niet automatisch fataal; leg dat uitdrukkelijk vast als u dat wilt.
• Het label “inspanningsverbintenis” of “resultaatsverbintenis” in het contract is niet doorslaggevend: de feitelijke samenwerking weegt minstens zo zwaar.
• Concrete, meetbare acceptatiecriteria en een uitgewerkte definition of done voorkomen discussie bij oplevering en bij beëindiging.
• Regel tussentijdse beëindiging en overdracht van broncode vooraf; daar biedt de wet u weinig houvast.

Veelgestelde vragen

Hieronder beantwoorden wij enkele vragen die bij agile-contracten vaak spelen.

Wat is een agile-contract?

Het geheel van afspraken waarmee u een agile-samenwerking vastlegt. In de praktijk bestaat dat uit een raamovereenkomst met het algemene kader en daaronder een nadere overeenkomst per opdracht, met de omvang, planning, prijs en acceptatiecriteria voor dat onderdeel.

Wat is het verschil tussen een inspannings- en een resultaatsverbintenis?

Bij een resultaatsverbintenis staat het overeengekomen resultaat centraal. Bij een inspanningsverbintenis moet worden beoordeeld of de leverancier de vereiste inspanning heeft geleverd. Dat verschil bepaalt waarover u in een geschil discussieert.

Is het label in het contract doorslaggevend?

Nee. Spreekt het contract van een resultaatsverplichting, dan kan de rechter op grond van de inhoud van de afspraken en de context toch oordelen dat feitelijk sprake is van een inspanningsverbintenis, en andersom. De feitelijke werkwijze weegt minstens zo zwaar.

Wie mag de backlog wijzigen?

Degene die de rol van product owner vervult. Leg vast wie dat is en of die persoon daarvoor mandaat heeft namens de opdrachtgever. Zonder die afspraak ontstaat discussie over wie verantwoordelijk is voor wijzigingen in de prioriteiten.

Waarom zijn acceptatiecriteria zo belangrijk?

Zonder duidelijke acceptatiecriteria staat niet vast waaraan het resultaat wordt getoetst. Daardoor ontstaat sneller discussie over de vraag of de sprint is geslaagd. Ze zijn in de praktijk belangrijker dan het label dat aan de verbintenis wordt gegeven.

Wie betaalt herstelwerk als het opgeleverde niet voldoet?

Zijn geen eindresultaten gedefinieerd, dan komen de inspanningen om alsnog aan de wensen te voldoen in beginsel als meerwerk voor rekening van de opdrachtgever. Dat is anders wanneer de leverancier zich niet aan de afspraken of zijn zorgplicht heeft gehouden, maar de bewijslast daarvoor ligt bij de opdrachtgever.

Hoe regelt u betaling bij agile werken?

Betaling koppelen aan één vast opleveringsmoment past slecht bij een werkwijze zonder vastgelegd eindresultaat. Gebruikelijke alternatieven zijn afrekenen per sprint, per functiepunt of per ureninzet. Leg de gekozen grondslag expliciet vast.

Kunt u agile werken combineren met een aanbesteding?

Dat vraagt om een aangepaste opzet, omdat een aanbesteding met een volledig vastgelegde omvang uitgaat van een vooraf bekend resultaat. Creëer in de aanbestedingsstukken ruimte voor een raamovereenkomst met flexibel in te vullen nadere opdrachten.

Wat regelt u over tussentijdse beëindiging?

Onder welke voorwaarden een partij kan stoppen, wat er gebeurt met reeds opgeleverde onderdelen en broncode, tegen welke vergoeding overdracht plaatsvindt, en wat een andere leverancier nodig heeft om het werk voort te zetten.

Bieden de NLdigital Voorwaarden 2025 voldoende houvast voor agile werken?

Slechts beperkt. Ze zijn de opvolger van de editie uit 2020 en voegen hoofdstukken toe over compliance, cyberbeveiliging, datadeling, kunstmatige intelligentie en onlineplatforms, maar voorzien de specifieke agile-aspecten niet. De voorwaarden uit 2020 blijven gelden wanneer u die bent overeengekomen. De agile-aspecten regelt u zelf in de nadere overeenkomst.

Bekijk ook onze pagina over advocaten IT-recht voor meer over agile-contracten en geschillen met IT-leveranciers.