Agile Projekte unter Vertrag: Teil 1: Vertragstyp, Leistungsumfang und Abnahme

Agile Arbeitsweisen gehören in IT-, Anlagenbau- und Bauprojekten heute zum Alltag. Anforderungen entstehen schrittweise, werden laufend priorisiert und nach jedem Zwischenergebnis angepasst. Der Vertrag dazu ist hingegen oft klassisch aufgebaut: Er enthält einen Festpreis, einen festen Endtermin, eine Vertragsstrafe und eine Abnahme am Ende.

Dieser Beitrag zeigt Ihnen, wie Sie den Vertrag für ein agiles Projekt aufbauen. Welcher Vertragstyp passt, wie wird der Leistungsumfang verbindlich und wann gilt ein Zwischenergebnis als abgenommen? Die Grundlinien sind in Österreich und Deutschland dieselben. Mitwirkung des Auftraggebers, Vertragsstrafe und Dokumentation behandelt Teil 2, die Unterschiede zwischen den beiden Rechtsordnungen Teil 3.

Zum Anwendungsbereich: B2B-Verträge nach österreichischem oder deutschem Recht über agil geführte Projekte, etwa Softwareentwicklung, Automatisierung, Anlagenbau und Bau. Gegenüber Verbrauchern gelten zusätzliche, strengere Schutzregeln.

Kurz zusammengefasst

Ein agiler Projektvertrag lässt Anforderungen offen, regelt aber genau, wie sie entstehen und verbindlich werden und wie mit Änderungen umgegangen wird. Ob Werkvertrag, Dienstvertrag oder Mischform vorliegt, hängt vom Inhalt des Vertrags ab und nicht von seiner Überschrift. Je mehr Erfolg, Festpreis und Fixtermin zugesagt werden, desto näher liegt der Werkvertrag und desto riskanter ist ein offener Leistungsumfang. Ein Backlog-Eintrag wird erst durch Freigabe verbindlich, und der Vertrag sollte festlegen, wann abgenommen wird.

Warum passen agile Arbeitsweise und klassischer Vertrag oft nicht zusammen?

Das österreichische ABGB und das deutsche BGB sind alt, das ABGB stammt von 1811, das BGB von 1900. Das Vertragsrecht darin geht davon aus, dass ein Vertrag im Streitfall beantworten kann, wer welche Leistung schuldet, bis wann, zu welchem Preis, wann sie mangelfrei ist und wer das Risiko trägt, wenn sich Anforderungen ändern.

Das agile Projektmanagement ist dagegen eine junge Methode, Projekte zu gestalten und abzuwickeln. Im agilen Projektalltag wird der Product Backlog laufend angepasst, Stakeholder bringen neue Wünsche ein, Sprint Reviews führen zu Änderungen, und Entscheidungen fallen später als geplant.

Ein klassischer Vertrag beantwortet die genannten Fragen für einen Plan, der von Anfang an feststeht, und beschreibt den Weg zum Ergebnis. Ein agiles Projekt braucht dagegen einen Vertrag für Veränderung. Er regelt, wie sich der Leistungsumfang entwickeln darf und welche Folgen das für Preis, Termin und Haftung hat.

Die agile Methode ist selten das Problem. Schwierig wird es, wenn der Vertrag so formuliert ist, als ließe sich das Projekt vollständig vorausplanen.

Werkvertrag, Dienstvertrag oder Mischform?

Bevor es um Backlog und Sprints geht, steht eine rechtliche Grundfrage: Welche Leistung schuldet der Auftragnehmer eigentlich? Bei einem Werkvertrag schuldet er ein bestimmtes Ergebnis. Bei einem Dienstvertrag stellt er hingegen seine Arbeitsleistung für eine gewisse Zeit zur Verfügung und verspricht keinen Erfolg. Das österreichische und das deutsche Recht unterscheiden hier gleich, und es spielt keine Rolle, ob das Projekt nach Scrum oder Kanban läuft.

Diese Einordnung wirkt sich auf fast alles aus, auf die Vergütung, die Mängelhaftung, die Abnahme, den Verzug und die Vertragsstrafe. Beim Werkvertrag trägt der Unternehmer weitgehend das Risiko, dass das Werk gelingt. Beim Dienstvertrag steht die Tätigkeit im Vordergrund.

Bei Software gilt in beiden Ländern: Standardsoftware, die dauerhaft gegen einmaliges Entgelt überlassen wird, ist ein Kauf. Individuell entwickelte oder erheblich angepasste Software wird überwiegend als Werkvertrag eingeordnet. Je individueller die Software ist, desto eher verlangt das Recht deshalb ein konkret beschriebenes Ergebnis.

Viele agile Verträge sind Mischformen, und das ist in Ordnung, solange sie sauber aufgebaut sind. Ein Entwicklungsteam mit laufender Beratung wird meist dienstvertragsnah und häufig nach Aufwand abgerechnet. Für bestimmte Releases oder Module wird ein konkretes Ergebnis mit Abnahme vereinbart, das ist werkvertragsnah. Die laufende Weiterentwicklung wird oft über einen Rahmenvertrag mit einzelnen Abrufen geregelt.

Wie der Vertrag heißt, spielt dabei keine Rolle, ob „agiler Werkvertrag“ oder „Development Agreement“. Es kommt darauf an, wer welchen Erfolg schuldet, wer das Risiko unklarer Anforderungen trägt und wann Vergütung entsteht. Besonders heikel wird es bei einem Rahmenvertrag. Er ist für agile Projekte praktisch, weil er Offenheit zulässt, kippt aber ins Haftungsrisiko, wenn er einen offenen Leistungsumfang mit Festpreis, Fixtermin und Vertragsstrafe kombiniert. Ein Rahmenvertrag sollte deshalb klar sagen, wann aus einer bloßen Möglichkeit eine verbindliche Leistungspflicht wird, zum Beispiel durch den Abruf oder die Freigabe eines Sprints.

Wie wird der Leistungsumfang in einem agilen Projekt verbindlich?

Auch ein agiler Vertrag braucht feste Punkte. Fest stehen sollten das Projektziel, der Budgetrahmen, technische und sicherheitsrelevante Vorgaben, Mindestfunktionen, Rollen, Eskalationswege und Abnahmekriterien. Beweglich bleiben dürfen die Reihenfolge der Umsetzung, die Priorisierung einzelner Funktionen und die Detailausgestaltung. Der Vertrag muss sagen, welche Beweglichkeit erlaubt ist und ab wann sie zur Vertragsänderung wird. Wenn im Backlog nur die Prioritäten geändert werden, ist das keine Vertragsänderung. Kommt hingegen eine neue Funktion dazu, die Aufwand, Termin oder Risiko verändert, braucht es eine dokumentierte Entscheidung.

Der Product Backlog kann Teil der Leistungsbeschreibung sein, darf dann aber keine informelle Wunschliste bleiben. Der Vertrag sollte regeln, wer Einträge einstellen darf, wer sie priorisiert und ab wann ein Eintrag verbindlich ist. Eine sinnvolle Grundregel lautet: Die Aufnahme in den Backlog ist noch keine Beauftragung, verbindlich wird ein Eintrag erst durch eine definierte Freigabe. Dabei helfen zwei Begriffe aus der agilen Praxis, die sich juristisch gut übersetzen lassen. Die „Definition of Ready“ beschreibt, wann eine Anforderung so klar beschrieben ist, dass sie in den verbindlichen Umfang aufgenommen werden kann. Die „Definition of Done“ beschreibt, wann eine Leistung als fertig gilt, und ist damit die Brücke zur Abnahme.

Dazu kommt ein Änderungsprozess, der leicht genug ist, um im Alltag auch genutzt zu werden. Er sollte klären, wer eine Änderung verlangen darf, wie sie beschrieben wird, wer die Auswirkungen auf Preis, Termin, Qualität und Risiko bewertet, wer entscheidet und ob schon vor der Freigabe umgesetzt werden darf. Ein überbürokratischer Prozess wird in der Praxis umgangen. Dann steht zwar ein sauberer Prozess im Vertrag, aber das Projekt läuft an ihm vorbei.

Auf gesetzliche Änderungsrechte können Sie sich in einem agilen IT-Projekt nicht verlassen. Der Änderungsprozess muss deshalb im Vertrag stehen. Für Bauverträge gibt es teils eigene gesetzliche oder normierte Regeln, die sich in Österreich und Deutschland unterscheiden (dazu Teil 3).

Wann ist ein Zwischenergebnis abgenommen?

Ein klassischer Werkvertrag kennt eine Abnahme am Ende. Agile Projekte liefern hingegen laufend Zwischenergebnisse, und der Vertrag muss entscheiden, welche rechtliche Bedeutung ein Sprint Review hat. Dafür gibt es vier Modelle:

• Sprint Review ohne Abnahme: Das ist leichtgewichtig und agil, verschiebt aber den Streit auf später.

• Teilabnahme pro Sprint: Sie schafft klare Zäsuren, bedeutet aber viel Dokumentation.

• Release-Abnahme: Das ist ein praktikabler Mittelweg, bei dem offene Punkte aus einzelnen Sprints nachverfolgbar bleiben müssen.

• Abnahme erst am Ende: Sie lässt sich einfach formulieren, birgt aber bei langen Projekten das Risiko eines großen Endstreits.

Welche rechtlichen Wirkungen eine Abnahme hat, regelt das Gesetz in Österreich und Deutschland unterschiedlich. Das betrifft die Frage, ob der Besteller zur Abnahme verpflichtet ist, wann sie als erklärt gilt und welche Folgen sie für Beweislast und Vertragsstrafe hat (dazu Teil 3). Für Ihren Vertrag heißt das: Legen Sie fest, was ein Sprint Review rechtlich bedeutet, und verlassen Sie sich nicht auf die gesetzlichen Wirkungen.

Praxis-Tipp: Die gefährlichste Kombination in einem agilen Projekt ist ein offener Leistungsumfang mit harten Rechtsfolgen, also ein Festpreis, ein Fixtermin und eine Vertragsstrafe bei Anforderungen, die erst im Projekt entstehen. Ein Vertrag, der „agil“ heißt, aber ein klassisches Festpreisprojekt regelt, bringt die Nachteile beider Welten.

Praxis-Elemente eines belastbaren agilen Projektvertrags

• Leistungsmodell: Der Vertrag sagt, ob ein Erfolg oder eine Tätigkeit geschuldet ist, und trennt werkvertragsnahe und dienstvertragsnahe Teile.

• Leistungsumfang: Der Vertrag beschreibt, welche Rolle der Backlog hat, wer priorisiert und wann ein Eintrag verbindlich wird.

• Fix und beweglich: Projektziel, Budgetrahmen und Abnahmekriterien stehen fest, die Reihenfolge der Umsetzung darf sich ändern.

• Änderungsprozess: Es ist geregelt, wer Änderungen verlangt, wer sie bewertet und entscheidet, wann Mehrvergütung entsteht und ob vor der Freigabe umgesetzt werden darf.

• Abnahme: Der Vertrag sagt, ob pro Sprint, pro Release oder erst am Ende abgenommen wird, welche Kriterien gelten und wie offene Punkte dokumentiert werden.

Häufige Fragen agilen Projektvertrag

Ist ein agiles Projekt ein Werkvertrag oder ein Dienstvertrag? Das hängt vom Vertragsinhalt ab. Wird ein konkretes Ergebnis geschuldet, etwa ein bestimmtes Release, liegt ein Werkvertrag nahe. Wird nur Entwicklungskapazität zur Verfügung gestellt, spricht das für einen Dienstvertrag. Häufig sind es Mischformen.

Kann ich bei einem agilen Projekt einen Festpreis vereinbaren? Ja, aber nur, wenn das geschuldete Ergebnis ausreichend konkret beschrieben ist. Ein Festpreis bei offenem Leistungsumfang verlagert das Risiko weitgehend auf den Auftragnehmer.

Genügt der Product Backlog als Leistungsbeschreibung? Er kann ein Teil davon sein. Der Vertrag muss dann aber regeln, wann ein Eintrag verbindlich wird und wer ihn freigibt.

Sollte ich pro Sprint abnehmen? Das hängt vom Projekt ab. Eine Abnahme pro Sprint schafft klare Zäsuren, bedeutet aber viel Dokumentation. Oft ist eine Abnahme pro Release der praktikable Mittelweg.

Gilt in Österreich und Deutschland dasselbe? Die Grundlogik ist sehr ähnlich. Bei der Abnahme und bei einzelnen gesetzlichen Folgen gibt es Unterschiede, die Teil 3 dieser Reihe zeigt.

Sie haben einen agilen Projektvertrag auf dem Tisch und wollen wissen, ob Leistungsmodell, Leistungsumfang und Abnahme zusammenpassen? Im Erstgespräch schauen wir gemeinsam auf die kritischen Stellen.

Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine individuelle rechtliche Beratung im Einzelfall.

Autorin: Alexandra Fuchs, Rechtsanwältin