Verträge für agile IT-Projekte

Start › IT-Recht › Agile Projekte

Scrum, Kanban oder hybride Modelle passen schlecht zum klassischen Werkvertrag mit festem Pflichtenheft. Trotzdem landen agile Projekte vor Gericht oft genau dort, weil der Vertrag die Arbeitsweise nicht abbildet. Wir gestalten Verträge für agile Softwareentwicklung, die zur gelebten Projektpraxis passen, und beraten Auftraggeber wie Dienstleister.

Werkvertrag oder Dienstvertrag bei Scrum?

Das Gesetz kennt keinen Vertragstyp „agiles Projekt“. Gerichte fragen, was nach dem Willen der Parteien geschuldet ist: ein funktionsfähiges Ergebnis (Werkvertrag, §§ 631 ff. BGB) oder das sorgfältige Tätigwerden (Dienstvertrag, §§ 611 ff. BGB). Steht am Ende eine bestimmte Software und zahlt der Kunde für deren Herstellung, tendieren die Instanzgerichte zum Werkvertrag, auch wenn im Sprint-Rhythmus gearbeitet wurde. Eine Leitentscheidung des Bundesgerichtshofs speziell zu Scrum-Verträgen gibt es mit Stand November 2026 nicht.

Die Einordnung hat erhebliche Folgen:

Thema	Werkvertrag	Dienstvertrag
Geschuldet	Erfolg, funktionierende Software	Tätigkeit nach Stand der Technik
Abnahme	erforderlich, Voraussetzung für Fälligkeit	keine
Mängelrechte	Nacherfüllung, Rücktritt, Minderung, Schadensersatz	nur Schadensersatz bei Pflichtverletzung
Vergütungsrisiko	beim Auftragnehmer	weitgehend beim Auftraggeber
Kündigung durch Kunden	jederzeit nach § 648 BGB, aber mit Vergütungsfolge	nach §§ 620 ff. BGB

Was ein agiler Vertrag regeln muss

• Rahmenvertrag mit Projektziel, Produktvision und groben Anforderungen, ohne ein starres Pflichtenheft vorzutäuschen
• Rollen: Product Owner beim Kunden mit Entscheidungsbefugnis, Scrum Master, Entwicklungsteam, Eskalationsweg
• Definition of Ready und Definition of Done als vertraglicher Maßstab für die Abnahmereife einzelner Inkremente
• Sprint-Abnahmen oder Teilabnahmen und eine Gesamtabnahme mit klaren Kriterien
• Vergütung: Time & Material mit Budgetdeckel, Festpreis pro Sprint oder agiler Festpreis mit Austauschregel für Backlog-Einträge
• Ausstiegspunkte nach jedem Sprint oder Release und die Vergütung bei vorzeitiger Beendigung
• Nutzungsrechte nach § 31 UrhG an Code, Dokumentation und Zwischenständen, Quellcodeherausgabe, Open-Source-Komponenten
• Mitwirkungspflichten des Kunden nach § 642 BGB, insbesondere Verfügbarkeit des Product Owners

Abnahme bei agiler Entwicklung

Ohne Abnahme wird die Vergütung im Werkvertrag nicht fällig, und die Verjährung der Mängelansprüche beginnt nicht. Seit 2018 gilt die Abnahmefiktion des § 640 Abs. 2 BGB: Setzt der Auftragnehmer nach Fertigstellung eine angemessene Frist und verweigert der Kunde die Abnahme nicht unter Angabe mindestens eines Mangels, gilt das Werk als abgenommen. In agilen Projekten wird diese Regel oft übersehen. Teilabnahmen je Inkrement sind nur wirksam, wenn der Vertrag sie vorsieht.

Arbeitnehmerüberlassung und Scheinselbständigkeit

Arbeiten externe Entwickler eng eingebunden im Team des Kunden und nehmen Weisungen des Product Owners entgegen, droht verdeckte Arbeitnehmerüberlassung nach dem AÜG. Wir achten darauf, dass Steuerung über Anforderungen und Backlog läuft und nicht über fachliche Einzelweisungen an einzelne Personen. Bei Freelancern ist zusätzlich das Risiko der Scheinselbständigkeit zu prüfen.

Öffentliche Auftraggeber

Für Behörden enthalten die EVB-IT Erstellung Optionen für agile Vorgehensweisen. Seit der Überarbeitung 2026 sehen sie bei neu entwickelter Software Open Source als Regelfall vor, einschließlich Software Bill of Materials.

So gehen wir vor

1. Wir klären mit Ihnen, wie das Projekt tatsächlich gesteuert werden soll und wer welches Risiko trägt.
2. Wir entwerfen Rahmenvertrag, Projektanlage mit Rollen und Abnahmeregeln und gegebenenfalls Einzelabrufe.
3. Während des Projekts prüfen wir auf Wunsch Change Requests, Abnahmeprotokolle und Eskalationen.

Häufige Fragen

Ist ein agiler Festpreis rechtlich möglich?

Ja. Üblich ist ein Festpreis für einen definierten Umfang an Story Points oder Sprints mit der Möglichkeit, Backlog-Einträge gleichen Umfangs auszutauschen. Der Mechanismus muss im Vertrag genau beschrieben sein, sonst streiten die Parteien später über Mehrvergütung.

Wer trägt das Risiko, wenn das Budget aufgebraucht ist und die Software nicht fertig?

Das hängt von der Vertragsgestaltung ab. Beim Werkvertrag grundsätzlich der Auftragnehmer, beim Dienstvertrag der Kunde. Eine klare Regelung zu Budgetwarnung, Priorisierung und Ausstieg verhindert, dass diese Frage erst im Prozess beantwortet wird.

Braucht es trotz Agilität ein Pflichtenheft?

Ein vollständiges Pflichtenheft nicht. Ohne dokumentierte Anforderungen, Akzeptanzkriterien und Sprint-Ergebnisse lässt sich aber kein Mangel und keine Vertragserfüllung beweisen. Backlog, Reviews und Protokolle sollten deshalb revisionssicher abgelegt werden.

Verwandte Themen

• Mustervertrag Softwareentwicklung
• IT-Projekt in Schieflage
• Softwarerecht
• EVB-IT
• Open Source