Agila kontrakt: deadlines, acceptans och ansvar i IT-projekt

Ett agilt kontrakt registrerar ett samarbete där slutresultatet inte är fastställt i förväg, så det måste reglera vem som prioriterar, när ett sprintresultat accepteras och om leveransdatum är bindande. Enligt nederländsk lag är ett leveransdatum i ett agilt projekt inte automatiskt en strikt deadline: domstolen tittar på kontraktet, arbetsmetoden och hur parterna faktiskt samarbetade, och inte ens en missad strikt deadline motiverar alltid hävning.

Inom agil utveckling arbetar parterna i korta sprintar och justerar produkten allt eftersom projektet fortskrider. Den här artikeln förklarar hur man kvalificerar leverantörens skyldighet, hur man strukturerar kontraktet, vad aktuell rättspraxis säger om deadlines och vad kunder och leverantörer bör kontrollera.

Varför behöver agilt arbete ett annat kontrakt?

Eftersom resultatet är ett rörligt mål. I ett traditionellt IT-projekt fastställer parterna en funktionell och teknisk design och leverantören lovar att leverera den vid ett bestämt datum; i agil utveckling levererar varje sprint en fungerande del och kunden justerar kursen baserat på demonstrationer.

Kontraktet måste därför avgöra fyra frågor som en traditionell specifikation besvarar i sig själv:

• vem som bestämmer specifikationerna och prioriteringarna: produktägaren på kundens sida;
• hur ändringar bearbetas i orderstocken (den prioriterade listan över funktionalitet som fortfarande ska byggas), planeringen och priset;
• när en del räknas som färdig, baserat på en definition av färdig och mätbara acceptanskriterier;
• huruvida avtalade leveransdatum är strikta eller vägledande.

Agilt arbete är svårt att kombinera med en offentlig upphandling där omfattningen är helt fastställd i förväg. En upphandlande myndighet som vill ha agil utveckling bör lämna utrymme i förfrågningsunderlaget för ett ramavtal med flexibelt definierade avropsuppdrag.

Är det en skyldighet att göra sitt bästa eller en resultatansvarsskyldighet?

I agila projekt kvalificeras leverantörens skyldighet ofta som en insatsförpliktelse (inspanningsverbintenis), eftersom inget fast slutresultat har överenskommits. Under en resultatförpliktelse (resultaatsverbintenis) utlovar leverantören ett specifikt beskrivet resultat.

Etiketten i avtalet är inte avgörande: domstolen granskar innehållet i arrangemangen och hur parterna faktiskt samarbetade. Enligt en resultatskyldighet är frågan om resultatet levererades; enligt en skyldighet att göra sitt bästa, om leverantören visade den omsorg som en rimligt kompetent och rimligt agerande IT-proffs har.

Artikel 6:74(1) i den nederländska civillagen (BW) utgör grunden för skadestånd för en hänförlig underlåtenhet att prestera, men den anger inte när det föreligger en underlåtenhet; det beror på hur förpliktelsen kvalificeras. Enligt artikel 6:248(1) BW har ett avtal också de konsekvenser som följer av rimlighet och rättvisa, vilket lämnar utrymme för att ta hänsyn till samarbetets flexibla karaktär.

Hur strukturerar man ett agilt kontrakt?

Vanligtvis i två lager. Ett ramavtal anger de allmänna reglerna: tillämpliga villkor, ansvar, sekretess, immateriella rättigheter och samarbetssätt. För varje uppdrag eller utgivning anger ett implementeringsavtal omfattning, planering, team, pris och acceptanskriterier.

Konkreta, mätbara acceptanskriterier per sprint är viktigare än etiketten på skyldighet. Utan dem finns det inget att testa resultatet mot, och tvister om huruvida en sprint lyckades uppstår snabbt. Inkludera en definition av "gjort" som inte bara täcker funktionalitet utan även kodkvalitet, dokumentation och överförbarhet.

Tidig uppsägning förtjänar mer uppmärksamhet än i ett traditionellt kontrakt, eftersom ett agilt projekt inte har någon fast slutpunkt. Kom överens om när varje part får avsluta, vad som händer med levererade komponenter och källkod, och hur arbetet överlämnas till en annan leverantör.

Standard IT-termer, såsom NLdigital Terms, reglerar agila aspekter endast i begränsad utsträckning. Kontrollera vilken utgåva som gäller och registrera de agila arrangemangen i implementeringsavtalet.

Vad säger rättspraxis om tidsfrister?

Det finns ingen generell regel att ett datum i ett agilt projekt aldrig är strikt. Två nyligen avkunnade domar visar hur domstolen väger mellan kontraktet och samarbetet.

Tingsrätten i Midden-Nederland, 2023: strikt tidsfrist, men ingen upphävande

I en dom i ECLI:NL:RBMNE:2023:5936 utvecklades programvara för ett vägningssystem med hjälp av scrum, med en överenskommen ledtid på cirka 24 veckor och senare fasta kalenderdatum. Domstolen fastslog att dessa datum var strikta tidsfrister, så leverantören var i dröjsmål utan meddelande om försummelse när de löpte ut.

Klientens hävning misslyckades ändå. Med tanke på projektets agila karaktär, det delade ansvaret mellan båda parter och det faktum att endast ett arbetsblock återstod, motiverade misslyckandet inte hävning enligt artikel 6:265 BW. Yrkandena om återbetalning och skadestånd ogillades.

Tingsrätten i Amsterdam, 22 april 2026: vägledande datum

I ECLI:NL:RBAMS:2026:3930 hävdade en kund att utvecklaren hade levererat en ny app för sent, överskridit budgeten och underhållit befintliga appar dåligt. Offerten använde tvåveckors scrum-sprintar och ett vägledande lanseringsdatum.

Domstolen fann inga strikta tidsfrister: lanseringsdatumet och sprintplaneringen var vägledande, och scrum-metoden krävde ett nära samarbete. Utan en strikt tidsfrist behövde klienten en giltig underrättelse om förfall, och dess underrättelser försatte inte utvecklaren i dröjsmål. Alla yrkanden avslogs.

Lärdomen: om du vill att ett datum ska vara strikt, ange det uttryckligen i kontraktet. Ett datum i en offert eller ett e-postmeddelande räcker oftast inte.

Vad bör du kontrollera som kund?

• Vem är er produktägare, och har den personen mandat att ändra orderstocken åt er räkning?
• Finns acceptanskriterier och en definition av vad som är klart registrerade för varje sprint eller release?
• Anger kontraktet uttryckligen vilka datum som är strikta tidsfrister?
• Inom vilken tidsfrist måste man testa och svara på en leverans, och vad händer om man inte gör det?
• När får du tillgång till källkoden och dokumentationen?
• Vad överlämnas vid förtida uppsägning, och till vilket pris?

Vad bör man kontrollera som leverantör?

• Är det tydligt att datum i offerter och planering är vägledande, om inte annat överenskommits?
• Dokumenterar ni produktägarens beslut och förändringar i orderstocken skriftligen?
• Registrerar ni när klienten inte lämnar in synpunkter, testkapacitet eller beslut i tid? Detta kan utgöra borgenärens betalningsförsummelse (artikel 6:58 BW).
• Är betalningsgrunden tydlig: per sprint, per timme, per funktionspunkt eller per resultat?
• Har du begränsat ditt ansvar och uteslutit följdskador i ramavtalet?

Vad kan vi göra för er med agila kontrakt?

Våra IT-jurister bistår IT-leverantörer och kunder med agila projekt. Vi kan:

• utarbeta eller granska ett ramavtal och implementeringsavtal för ett agilt projekt;
• formulera acceptanskriterier, en definition av klart och tydliga deadlineklausuler;
• utarbeta ett utträdesavtal för förtida uppsägning och överföring till en annan leverantör;
• bedöma om en leverantör har försummat avtalet och om hävning är möjlig;
• utarbeta ett meddelande om försummelse eller ett svar på ett sådant, och driva förfaranden om försening eller uppsägning.

Läs mer om vad en IT-jurist gör.

Sammanfattning

• Ett agilt kontrakt består vanligtvis av ett ramavtal och implementeringsavtal per uppdrag.
• Leverantörens skyldighet är ofta en skyldighet att göra sitt bästa; etiketten i kontraktet är inte avgörande.
• Mätbara acceptanskriterier och en definition av vad som är klart förhindrar tvister om huruvida en sprint lyckades.
• Huruvida ett leveransdatum är en strikt tidsfrist beror på avtalet och samarbetet, så ange det uttryckligen; inte ens en missad strikt tidsfrist motiverar automatiskt hävning (ECLI:NL:RBMNE:2023:5936).
• Reglera förtida uppsägning, källkod och överlämning till annan leverantör i förväg.

Vanliga frågor och svar