Agile Verträge rechtssicher gestalten | IT-Medienrecht

Agile Entwicklungsverträge: Rechtssichere Gestaltung und Praxis-Checkliste

Grundlagen agiler Vertragsgestaltung

Warum eigene Vertragslogik für Agile Softwareentwicklung?

Agile Softwareentwicklung arbeitet iterativ, inkrementell und empirisch. Anforderungen werden im Product Backlog priorisiert, in Sprints verfeinert und in User Stories umgesetzt. Diese Methoden erfordern eine spezielle vertragliche Ausgestaltung.

Planungssicherheit entsteht hier weniger durch eine starre Leistungsbeschreibung. Vielmehr sind Taktung, Transparenz und Steuerung über Velocity, Sprint Reviews sowie eine belastbare Definition of Done entscheidend. Klassische Entwicklungsverträge mit einmaliger, umfassender Spezifikation greifen hier oft zu kurz. Ziel, Weg und Aufwand stehen zu Projektbeginn nicht vollständig fest.

Werk- oder Dienstvertrag: Die rechtliche Einordnung

Rechtlich stellt sich die Einordnung zwischen Dienstvertrag (§ 611 BGB) und Werkvertrag (§ 631 BGB). Bei agilen Setups lassen sich beide Modelle abbilden:

• Dienstvertraglich: Der Anbieter schuldet lediglich Tätigkeiten in Sprints. Ein konkreter Erfolg ist nicht definiert. Die Vergütung erfolgt typischerweise nach Zeit und Material (time & material). Mehr dazu, warum "schlechte Arbeit" nicht zur Zahlungsverweigerung führt, können Sie in unserem Blog nachlesen.
• Werkvertraglich: Pro Sprint oder pro Inkrement wird ein bestimmter, abnahmefähiger Erfolg vereinbart. Maßgeblich sind hierbei Definition of Ready, Definition of Done, Akzeptanzkriterien und ein klar definierter Abnahmeprozess (§ 640 BGB).

In der Praxis finden sich oft Mischmodelle. Hierbei erfolgt die Erbringung der Sprintarbeit dienstvertraglich, während einzelne inkrementelle Ergebnisse werkvertraglich teilabgenommen werden. Rechtssicherheit entsteht durch eine eindeutige Zuweisung, welcher Teil als „Werk“ mit Abnahmepflicht gilt und wann lediglich Tätigkeiten geschuldet sind.

Besondere Relevanz der Mitwirkungspflichten

Agile Methoden setzen eine intensive Mitwirkung des Auftraggebers voraus. Dies betrifft den Product Owner, schnelle Entscheidungen, Priorisierung, Testdaten und Zugangssysteme. Fehlt diese Mitwirkung, drohen Verzögerungen und Projektrisiken.

Eine saubere Mitwirkungsklausel mit klaren Rechtsfolgen ist daher unerlässlich. Maßgeblich ist hier § 642 BGB (Annahmeverzug bei unterlassener Mitwirkung). Ergänzend sind klare Kooperations- und Eskalationsmechanismen zu definieren.

Abgrenzung zum klassischen Entwicklungsvertrag

Der klassische Vertrag koppelt Vergütung und Termine an eine fixierte Leistungsbeschreibung (Lasten-/Pflichtenheft). Er sieht eine einmalige Endabnahme und Gewährleistung (§§ 633, 634 BGB) vor. Agile Verträge hingegen arbeiten mit rollierenden Backlogs, Sprints, Teilabnahmen und Budgetkappen.

Die zentrale Abgrenzung liegt im Steuerungsmechanismus: Statt einer einmaligen Spezifikation wird die inhaltliche Zielerreichung sprintweise justiert. Dies erfordert andere Vergütungs-, Abnahme- und Änderungsregeln. Eine detaillierte Vertragsgestaltung im Kontext agiler Arbeitsmethoden ist entscheidend.

Die Vertragsarchitektur agiler Projekte

Empfohlene Dokumentstruktur

Für agile Entwicklungsverträge in der Praxis hat sich eine modulare Architektur bewährt:

• Rahmenvertrag/Master Service Agreement (MSA): Dieser beinhaltet allgemeine Regelungen zu IP, Haftung, Vertraulichkeit, Datenschutz und Konfliktlösung.
• Statement of Work (SOW) oder Leistungs- und Governance-Beschreibung: Hier werden das agile Setup, Rollen, Events, Artefakte, Definition of Ready/Done, Schätzregeln und Abnahmeprozesse detailliert beschrieben.
• Product-Backlog-Anhang: Dieser enthält die initialen Epics/User Stories, Akzeptanzkriterien und deren Priorisierung.
• Sprint-Annex oder Sprint-Protokolle: Hierin werden Sprintziel, Commitments, Story-Liste, Story-Point-Schätzungen, Testfälle und Abnahmeergebnisse festgehalten.
• Change- und Budgetsteuerung: Regelungen zu Capped Budget, Änderungsmechanismen und Eskalationsstufen.

Rollen und Verantwortlichkeiten im agilen Vertrag

Die Rollen aus Scrum oder einem vergleichbaren Rahmen sollten juristisch „übersetzt“ werden, um klare Verantwortlichkeiten zu schaffen:

• Product Owner: Verantwortet Backlog-Priorisierung, Abnahmeentscheidungen, fachliche Vorgaben, Testdaten und Stakeholder-Management.
• Anbieterteam: Liefert Inkremente, dokumentiert, testet entsprechend der Definition of Done und weist Impediments aus.
• Delivery-Governance: Ein Lenkungskreis mit festen Zyklen, verbindlichen Eskalationsregeln und Protokollpflicht.

Wichtig ist die eindeutige Zuweisung von Entscheidungsbefugnissen: Wer darf Stories freigeben, Abnahmen erteilen oder Budgets verschieben? Schweigen und Untätigkeit müssen klar definierte Rechtsfolgen auslösen, wie Fristen und Fiktionen.

Definition of Ready und Definition of Done: Klare Standards

• Klarer Nutzen der Story.
• Definierte Akzeptanzkriterien.
• Verfügbarkeit von Testdaten.
• Geklärte Abhängigkeiten.

• Klarer Nutzen der Story.
• Definierte Akzeptanzkriterien.
• Verfügbarkeit von Testdaten.
• Geklärte Abhängigkeiten.

• Code-Standards
• dokumentierte Tests
• erfolgreiche Build-Pipelines
• Sicherheitsprüfungen
• Reviews

Story Points, Velocity und Messbarkeit im agilen Projekt

Story Points sind ein relativer Komplexitätsmaßstab, keine Zeiteinheiten. Der Vertrag sollte dies ausdrücklich festhalten, um Irrtümer auszuschließen. Dennoch benötigen Budget- und Kapazitätssteuerung belastbare Regeln:

• Eine Umrechnungsklausel dient nur zu Planungszwecken (z. B. durchschnittliche Velocity des Teams) ohne Gewährleistungscharakter.
• Es gibt kein Leistungsversprechen auf eine bestimmte Velocity, sondern lediglich eine Best-Efforts-Zusage unter Einhaltung der Methodik.
• Transparente Dokumentation in Sprint-Reports, Burn-Down/Burn-Up-Charts und Cumulative Flow Diagrammen ist erforderlich.

Governance und Eskalationsmanagement

Die Etablierung von Regelmeetings mit Protokollpflicht ist entscheidend:

• Sprint Planning: Festlegung von Story-Liste, Schätzung, Sprintziel und Risikoanalyse.
• Sprint Review: Abnahmeentscheidungen, Freigabeprotokoll und eine Fiktion bei Fristversäumnis.
• Retrospektive: Erstellung eines Maßnahmenplans zur kontinuierlichen Verbesserung.
• Lenkungsausschuss: Monatliche Treffen zur Budgetsteuerung, Scope-Trade-offs und Risikomanagement.

Fehlen Entscheidungen, greifen Eskalationsstufen bis hin zu Interimsentscheidungen des Lenkungskreises, um Stillstand zu vermeiden.

Leistung, Abnahme und Mängelrechte in agilen Entwicklungsverträgen

Ergebnisdefinition im agilen Kontext

Auch agile Projekte benötigen klare Ergebnismaßstäbe. Empfehlenswert ist die Kopplung von User Stories an messbare Akzeptanzkriterien. Für jedes Inkrement ist festzulegen, ob es als abnahmefähiges Werkteil gilt. Dies ermöglicht Teilabnahmen (§ 640 BGB) und verlagert Gewährleistungsrisiken planvoll auf die Sprint-Ebene.

Sprint- und Teilabnahme: Ein rechtssicherer Prozess

Ein rechtssicherer Abnahmeprozess umfasst mehrere Punkte:

• Abnahmereife: Sie ist gegeben bei Erfüllung der Definition of Done und der Story-spezifischen Akzeptanzkriterien.
• Formale Abnahmeerklärung: Der Product Owner erteilt diese binnen einer Frist (z. B. fünf Werktage nach dem Review).
• Abnahmefiktion: Bei Untätigkeit des Auftraggebers (§ 640 Abs. 2 BGB) gilt die Abnahme als erteilt, wenn der Anbieter die Abnahmereife angezeigt und eine angemessene Frist gesetzt hat.
• Dokumentierte Mängelklassen: Bei geringfügigen Mängeln ist eine Abnahme unter Vorbehalt zulässig.

Bewährt ist ein Sprint-Abnahmeprotokoll, das folgende Elemente enthält:

• Liste der fertiggestellten Stories.
• Testergebnisse und entsprechende Nachweise.
• Die Entscheidung des Product Owners je Story (abgenommen, abgenommen unter Vorbehalt, abgelehnt mit Begründung).
• Eine Frist zur Nacherfüllung bei abgelehnten Stories.

Gewährleistung und Haftung bei agilen Werken

Für als Werk definierte Inkremente gelten die Mängelrechte nach § 634 BGB. Dazu gehören Nacherfüllung, Selbstvornahme, Minderung, Rücktritt und Schadensersatz. Die Verjährung kann sachgerecht bemessen werden (§ 634a BGB).

Häufig beträgt diese 12 Monate im B2B-Verhältnis für Standard-Softwarebestandteile. Bei individuell erstellter Software sind differenzierte Fristen üblich. Für rein dienstvertragliche Leistungen greifen die allgemeinen Leistungsstörungsrechte (§§ 280 ff. BGB). Auch die Mangelhaftigkeit von SaaS-Lösungen ist hier relevant.

Der agile Change-Mechanismus

Agile Projekte verändern Scope und Prioritäten regelmäßig. Eine Change-Klausel sollte daher klar regeln:

• Wer Change-Requests anstoßen darf.
• Wie der Impact auf Budget, Termin und Qualität bewertet wird.
• Die Entscheidung und Protokollierung im Lenkungsausschuss oder im Sprint Planning.
• Einen automatischen Budget- oder Cap-Abgleich bei Scope-Zuwachs.

Wichtig ist, dass keine konkludenten Änderungen durch bloße Diskussionen in Tools entstehen. Es bedarf stets einer formalen Festlegung.

Tests, Qualität und Security in agilen Verträgen

Die Definition of Done sollte zwingende Qualitätsanforderungen enthalten. Dazu zählen Code-Linting, Unit-Tests mit Mindestabdeckung, automatisierte Builds und Peer Reviews. Ebenso wichtig sind Sicherheits-Checks (z. B. Dependency-Scanning) und deren Protokollierung.

Für Security-relevante Projekte sind zusätzliche Pflichten zu definieren. Dazu gehören Bedrohungsmodelle, Penetrationstests und Notfallpläne. So werden Qualitätsdiskussionen justiziabel und nachvollziehbar.

Vergütung, Budgetsteuerung und Controlling agiler Projekte

Vergütungsmodelle für agile Projekte

Vier Modelle dominieren bei der Vergütung in agilen Projekten:

• Time & Material mit Cap: Abrechnung nach Stundensätzen, wobei eine Obergrenze als Budgetsteuerungsinstrument dient.
• Sprintpauschalen: Ein Festpreis je Sprint bei vereinbarter Kapazität und Teamzuschnitt. Anpassungen erfolgen bei Teamwechseln.
• Preis je Story Point: Vergütung pro Punkt. Dies erfordert klare Regeln für Schätzung, Re-Schätzung und Ausschlüsse. Wichtig ist die Klarstellung, dass Story Points kein Zeitversprechen sind.
• Hybrid: Eine Kombination aus T&M für Discovery/Architektur und Werkvergütung für definierte Inkremente oder Releases.

Die Wahl des Modells hängt von der Risikobereitschaft und dem Reifegrad des Backlogs ab. Ein dynamischer Wechsel je Projektphase ist möglich, muss aber vorab vertraglich vorgesehen werden.

Budgetkappen, Stop-Loss und Priorisierung

Unverzichtbar sind harte Budgetkappen mit einer Stop-Loss-Mechanik. Das Annähern an 80 % des Caps löst die Pflicht zur Budgetkonferenz aus. Bei 100 % Cap stoppt die Entwicklung, bis eine schriftliche Erhöhung erfolgt.

Parallel wird das Backlog so priorisiert, dass maximaler Business Value innerhalb des Caps realisiert wird. Ein „automatisches“ Überziehen des Caps durch Mehraufwand ist somit ausgeschlossen.

Transparenz- und Reportingpflichten

Rechtlich durchsetzbare Transparenz entsteht durch:

• Wöchentliche Aufwandsreports je Rolle und Story.
• Sprint-Reports mit Velocity, Stories Done/Not Done, Impediments und Burn-Down-Charts.
• Monatsreport an den Lenkungsausschuss mit Budgetverbrauch, Forecast, Risiken und Maßnahmen.
• Auditrecht auf die Projekttools und Repositories nach vorheriger Ankündigung.

Fehlt diese Transparenz, kippt das Risikoprofil des Projekts. Reporting wird daher zu einer Kardinalpflicht.

Regelung von Nebenkosten und Drittleistungen

Reisekosten, Lizenzen, Cloud-Ressourcen, Testgeräte und Subunternehmer sind separat zu regeln. Subprozessoren dürfen nur mit Zustimmung eingesetzt werden. Dabei müssen gleiche Vertraulichkeits- und Sicherheitsstandards gewährleistet sein.

Drittsoftware muss lizenziert sein, und Open-Source-Einsatz erfordert Compliance-Regeln. Ein Beispiel für die rechtlichen Grundlagen von Open Source in der Softwareentwicklung finden Sie hier.

Beispielhafte Vergütungsklauseln

• Time & Material mit Cap: „Der Anbieter rechnet monatlich nach tatsächlichem Aufwand gemäß Anlage Preisliste ab. Die Gesamtvergütung ist auf den Budgetrahmen begrenzt. Bei Erreichen von 80 % des Budgetrahmens findet eine Budgetkonferenz statt; ohne schriftliche Budgeterhöhung ruht die Leistungspflicht nach Ausschöpfen des Budgetrahmens.“
• Sprintpauschale: „Je Sprint wird eine Pauschale fällig, die die in Anlage Teamzuschnitt ausgewiesenen Rollen umfasst. Änderungen des Teamzuschnitts bewirken eine proportionale Anpassung der Pauschale ab dem Folgesprint.“
• Story-Point-Modell: „Die Parteien vereinbaren eine Vergütung pro Story Point. Story Points dienen als relativer Komplexitätsmaßstab und stellen keine Zeiteinheit dar. Eine bestimmte Velocity wird nicht geschuldet.“

Rechtliche Aspekte: Mitwirkung, IP, Datenschutz und Compliance im agilen Kontext

Mitwirkungspflichten des Auftraggebers und Rechtsfolgen

Zu den Pflichten des Auftraggebers gehören:

• Die Benennung eines entscheidungsbefugten Product Owners.
• Die rechtzeitige Bereitstellung von Testdaten, Zugängen und Ansprechpartnern.
• Die Teilnahme an Sprint-Zeremonien und Abnahmeentscheidungen innerhalb der Fristen.
• Die Priorisierung und Klärung von Abhängigkeiten.

Rechtsfolgen bei Verzögerungen umfassen:

• Leistungsverweigerungsrecht des Anbieters bei fehlender Mitwirkung.
• Terminverlängerung und Mehraufwandvergütung.
• Zahlungsfälligkeit für Leerlauf gemäß § 642 BGB.
• Eskalation bis hin zur außerordentlichen Kündigung bei anhaltenden Pflichtverletzungen (§ 314 BGB).

Rechte an agilen Arbeitsergebnissen (IP)

Für kundenspezifische Software sind ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrechte am Quell- und Objektcode üblich (§§ 31, 69a ff. UrhG). Wichtig sind hierbei:

• Eine klare Rechtekette bei Subunternehmern. Die Einräumung wird spätestens mit Zahlung fällig.
• Herausgabe- und Übergabepflichten: Quellcode, Build-Skripte, Dokumentation, Infrastruktur- und Secrets-Übersicht.
• Beschränkungen auf Standardbausteine des Anbieters (Frameworks, Libraries, Tooling), die nur einfache Nutzungsrechte begründen, sofern dies vereinbart ist.
• Verzicht oder Ausgestaltung des Urheberbenennungsrechts (§ 13 UrhG) in B2B-Projekten.

Der Blogartikel "Rechtekette im Game Development" bietet weitere Einblicke in die Sicherung von Rechten an Arbeitsergebnissen.

Open Source und der Einsatz von KI-Assistenz

Open-Source-Komponenten sind bei vorheriger Freigabe und dokumentierter Lizenzprüfung zulässig. Copyleft-Lizenzen (z. B. GPL) bedürfen einer gesonderten Zustimmung, wenn eine Quelloffenlegung droht. Eine OSS-Bill of Materials (SBOM) ist bereitzustellen; Sicherheitsupdates sind Teil der Wartung.

Bei der Nutzung von KI-Assistenzsystemen in der Entwicklung sind ebenfalls Regeln zu treffen:

• Keine Einspeisung vertraulicher Kundendaten in externe Modelle ohne Freigabe.
• Dokumentation der Herkunft wesentlicher Codeabschnitte.
• Sicherstellung, dass keine Rechte Dritter verletzt werden.
• Klare Verantwortlichkeit für Qualität und Sicherheit des von KI generierten Codes.

Weitere Informationen zu Rechten und KI finden Sie unter "KI-generierte Inhalte: Wem gehören die Rechte?".

Datenschutz und Geheimnisschutz in agilen Projekten

Verarbeitet der Anbieter personenbezogene Daten des Auftraggebers, ist ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO erforderlich. Dieser umfasst Technische und Organisatorische Maßnahmen (TOMs), Subprozessoren, Auditrechte und ein Löschkonzept. Mehr dazu finden Sie in unserem Artikel "Was gehört in einen AVV?".

Geschäftsgeheimnisse werden durch das GeschGehG geschützt. Hierfür sind Vertraulichkeitsklauseln, Zugriffskontrollen, das Need-to-know-Prinzip und ein Schutzstufenmodell für Quellcode und Artefakte notwendig.

Betrieb, Wartung und Service Level Agreements (SLA)

Nach der Entwicklung schließt sich häufig ein Wartungs- und Supportvertrag an. Dieser sollte folgende Inhalte umfassen:

• Störungsannahme sowie Reaktions- und Behebungszeiten (SLA) mit abgestuften Schweregraden.
• Patch- und Release-Management sowie Kompatibilitätspflege.
• Sicherheitsmonitoring und Incident-Response-Prozesse.
• Vergütung als Retainer mit Kontingenten plus Zusatzaufwand zu Sätzen des MSAs.

Haftung, Kündigung und Exit-Strategien für agile Projekte

Haftungsregelungen und Limitierungen

Haftungsregeln müssen die Kardinalpflichten und typische Projektrisiken abbilden:

• Unbeschränkte Haftung für Vorsatz und grobe Fahrlässigkeit.
• Körper- und Gesundheitsschäden sowie Produkthaftung bleiben unberührt.
• Bei einfacher Fahrlässigkeit haftet der Anbieter nur für Kardinalpflichtverletzungen. Diese Haftung ist begrenzt auf den typischen, vorhersehbaren Schaden (§§ 280, 276 BGB).
• Datenverlustschäden werden nur ersetzt, soweit regelmäßige Datensicherung vereinbart und nachweisbar ist.
• Haftungscaps je Vertragsjahr, Ausschluss von entgangenem Gewinn und indirekten Schäden, soweit rechtlich zulässig.

Es ist wichtig, die Klauselkontrolle nach §§ 305 ff. BGB zu beachten. § 309 BGB gilt zwar primär im B2C-Bereich, wirkt aber als Leitbild in B2B-Konstellationen über § 307 BGB.

Kündigungsrechte im agilen Vertrag

Eine gestaffelte Kündigungslogik ist ratsam:

• Außerordentliche Kündigung aus wichtigem Grund (§ 314 BGB) bei schweren Pflichtverletzungen.
• Werkvertragliche freie Kündigung (§ 648 BGB) für definierte Werkteile. Hierbei sind die bis dahin erbrachten Leistungen und entgangenen Gewinnanteile zu vergüten.
• Dienstvertragliche Kündigung nach § 621 BGB oder vertraglich festgelegt. Hier erfolgt die Abrechnung der Sprints bis zum Wirksamwerden.
• Sprintweise Kündigungsmöglichkeit zum Sprintende mit klaren Folgen für Budget, Repositories und Lizenzen.

Exit- und Übergaberegelungen für Projekte

Ein sauberer Exit verhindert den Lock-in und umfasst:

• Die Pflicht zur Übergabe von Quellcode, Dokumentation, Tickets, Architektur- und Betriebsdokumenten in gängigen Formaten.
• Die Übergabe der Zugänge und Rechte an Repositories, CI/CD und Cloud-Accounts. Dies sollte über ein zweistufiges Verfahren mit Abnahme der Übergabe erfolgen.
• Unterstützung bei der Transition an Dritte zu definierten Sätzen.
• Optional ein Software-Escrow für kritische Komponenten.
• Die Löschung oder Rückgabe vertraulicher Daten nach einer dokumentierten Checkliste.

Vorteile und Nachteile des agilen Vertragsmodells

Vorteile für Auftraggeber:

• Frühe Mehrwerte durch inkrementelle Lieferungen.
• Transparenz über Fortschritt und Budget.
• Möglichkeit zur Prioritätsverschiebung basierend auf Geschäftsnutzen.
• Risikoentlastung durch Teilabnahmen und Stop-Loss-Mechanismen.

Vorteile für Anbieter:

• Realistische Steuerung des Scopes, weniger Nachtragsstreit.
• Planbare Teams durch Sprinttaktung und Governance.
• Vergütung nah am Aufwand reduziert Kalkulationsrisiken.

Nachteile für Auftraggeber:

• Weniger Preis- und Terminfixität, wenn das Backlog unreif ist.
• Erhöhte Mitwirkungsintensität und Ressourcenbindung im Fachbereich.
• Gefahr von „Scope Creep“, wenn die Governance schwach ist.

Nachteile für Anbieter:

• Hoher Dokumentations- und Reportingaufwand.
• Abhängigkeit von Mitwirkung und Produktentscheidungen des Auftraggebers.
• Diskussionen um Story-Point-Schätzungen und Velocity, wenn vertraglich schlecht gefasst.

Praxis-Checkliste für agile Vertragsklauseln

Leistungs- und Ergebnisdefinition:

• Klare Definition of Ready/Done und Story-spezifische Akzeptanzkriterien.
• Regel, welche Artefakte in die Abnahme einfließen (Code, Tests, Dokumentation).

Abnahme:

• Sprint-Review als Abnahmefenster mit Frist zur Erklärung.
• Abnahmefiktion bei Untätigkeit; Abnahme unter Vorbehalt bei geringfügigen Mängeln.

Vergütung und Budget:

• Wahl des Vergütungsmodells mit Cap und Stop-Loss.
• Reportingpflichten, Forecast, Eskalationsstufen.
• Regeln zu Change-Requests und deren Budgetwirkung.

Mitwirkung:

• Namentlicher Product Owner, Verfügbarkeitsfenster, Entscheidungsfristen.
• Folgen bei Mitwirkungsmängeln (§ 642 BGB), inklusive Vergütung von Stillstandszeiten.

IP und Übergabe:

• Rechtekette, Umfang der Rechte (§§ 31, 69a ff. UrhG), Zeitpunkt des Übergangs.
• Herausgabepflichten und Exit-Checkliste, Escrow optional.

Open Source und KI:

• Freigabeprozess, SBOM, Copyleft-Regeln.
• Einsatzregeln für KI-Assistenz, Schutz von Geschäftsgeheimnissen.

Datenschutz und Sicherheit:

• AVV nach Art. 28 DSGVO bei Datenverarbeitung, TOMs, Subprozessoren, Audit.
• Security-Standards in der Definition of Done, Incident-Response.

Haftung:

• Staffelung nach Verschuldensgraden, Haftungscap, Ausschlüsse im rechtlichen Rahmen.
• Besondere Risiken (z. B. Datenverlust) und Sicherungsobliegenheiten.

Kündigung und Streitlösung:

• Gestaffelte Kündigungsrechte (Sprintende, § 648, § 314 BGB).
• Mediations- oder Schlichtungsklausel vor gerichtlichen Schritten.

Konkrete Formulierungsbeispiele für agile Verträge

Mitwirkung:
„Der Auftraggeber stellt einen entscheidungsbefugten Product Owner zur Verfügung, der an allen Sprint-Zeremonien teilnimmt und binnen fünf Werktagen Entscheidungen trifft. Unterbleiben erforderliche Mitwirkungen, verlängern sich Fristen angemessen; der Anbieter kann Stillstandszeiten und Mehraufwand abrechnen. § 642 BGB bleibt unberührt.“

Abnahme:
„Die Parteien führen am Ende eines jeden Sprints ein Review durch. Der Anbieter zeigt die Abnahmereife an. Der Auftraggeber erklärt binnen fünf Werktagen die Abnahme je Story oder benennt konkrete Mängel. Erfolgt keine Erklärung, gilt die Abnahme als erteilt (§ 640 Abs. 2 BGB). Geringfügige Mängel hindern die Abnahme nicht; die Nacherfüllung erfolgt innerhalb angemessener Frist.“

Story Points:
„Story Points sind ein relativer Komplexitätsmaßstab und stellen keine Zeiteinheit dar. Eine bestimmte Velocity wird nicht geschuldet. Schätzungen dienen ausschließlich der Kapazitäts- und Budgetplanung.“

Vergütung Cap:
„Die Vergütung erfolgt auf T&M-Basis gemäß Anlage Preisliste, begrenzt durch den Budgetrahmen. Bei Erreichen von 80 % des Budgetrahmens erfolgt eine Budgetkonferenz; nach Ausschöpfen des Rahmens ruht die Leistungserbringung, bis eine schriftliche Budgeterhöhung vorliegt.“

Rechteübertragung:
„Mit Abnahme und Zahlung erhält der Auftraggeber die ausschließlichen, räumlich und zeitlich unbeschränkten Nutzungsrechte an den individuellen Arbeitsergebnissen einschließlich Quellcode und Dokumentation. Standardbausteine des Anbieters verbleiben beim Anbieter; hieran erhält der Auftraggeber einfache Nutzungsrechte in dem zur Verwendung der Arbeitsergebnisse erforderlichen Umfang.“

Open Source:
„Der Einsatz von Open-Source-Komponenten bedarf der Freigabe. Der Anbieter stellt eine SBOM zur Verfügung und gewährleistet Lizenz-Compliance. Copyleft-Lizenzen, die eine Offenlegung der Auftraggebersoftware auslösen, bedürfen gesonderter Zustimmung.“

Haftung:
„Für Vorsatz und grobe Fahrlässigkeit haftet der Anbieter unbeschränkt. Bei einfacher Fahrlässigkeit haftet er nur für die Verletzung wesentlicher Vertragspflichten, begrenzt auf den vorhersehbaren, typischen Schaden. Die Haftung für Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit bleibt unberührt.“

Kündigung:
„Jede Partei kann aus wichtigem Grund kündigen (§ 314 BGB). Der Auftraggeber kann werkvertragliche Teile gemäß § 648 BGB frei kündigen; bereits erbrachte Leistungen sind zu vergüten. Kündigungen sind zum Sprintende möglich, sofern nicht ein wichtiger Grund eine fristlose Beendigung rechtfertigt.“

Exit:
„Der Anbieter unterstützt die Transition auf einen Dritten für bis zu 20 Personentage nach Vertragsende. Quellcode, Repositories, CI/CD-Skripte, Dokumentation und Zugangsdaten werden vollständig und in gängigen Formaten übergeben; die Übergabe unterliegt einer Abnahme durch den Auftraggeber.“

Fazit

Agile Entwicklungsverträge funktionieren, wenn das juristische Korsett die Methode nicht erstickt, sondern operationalisiert. Dies bedeutet, klare Governance, sprintfähige Ergebnisdefinitionen, belastbare Abnahme- und Mängelmechanismen sowie transparente Budgetsteuerung zu etablieren. Zudem sind harte Mitwirkungspflichten und ein ausgewogenes Vergütungsmodell unerlässlich.

Die bewusste Einordnung einzelner Projektteile als Werk oder Dienst vermeidet spätere Streitigkeiten um Abnahme, Gewährleistung und Haftung. Wer die agilen Artefakte (Backlog, Definition of Done, Sprintprotokolle) als rechtsverbindliche Messlatte etabliert und mit einem straffen Change- und Reportingregime verknüpft, erhält ein praxistaugliches, revisionssicheres Vertragswerk. Dieses erlaubt Flexibilität, ohne die Rechtssicherheit zu opfern.