Agile Projekte nach Scrum Methodik mit Festpreisbindung

Das agile Festpreisprojekt strebt eine zum Projektstart vollständige, wenn auch noch nicht detaillierte Beschreibung des Vertragsgegenstandes an. Die beiden Vertragspartner (Auftraggeber, Auftragnehmer) treffen gemeinsam Annahmen bezüglich des Geschäftswertes, des Umsetzungsrisikos, dem Aufwand und den Kosten. Auf Grundlage dieser Annahmen wird ein indikativer Festpreisrahmen vereinbart, der noch nicht bindend ist. Mitunter einer der wesentlichen Vorteile ist die Risikoteilung - beide Vertragsparteien tragen den Mehraufwand für ungeplante Änderungen mit. Es kann auch die Möglichkeit eines Vertragsausstiegs für beide Parteien (Ausstiegspunkte) vereinbart werden.

In einer Testphase (mehrere Sprints; Checkpoint-Phase) beginnt die erste Umsetzung. Am Ende dieser Phase wird aus der so genannten Velocity der durchschnittliche und tatsächliche Aufwand ermittelt und mit den vor Projektbeginn getroffenen Annahmen abgeglichen - die Vertragsbedingungen werden zu diesem Zeitpunkt festgelegt (Festlegung der Sprint-Festpreis-Baseline).

Ermittlung des Sprint-Festpreises

Für die Ermittlung des Festpreises werden folgende Kriterien zugrunde gelegt:

• Die Beschreibung des Vertragsgegenstandes erfolgt auf einer groben Ebene (Projektziele, Themen, Anforderungen und User Stories/Epics)
• Ein erfahrener Product Owner des Auftraggebers hat den Product Backlog in Absprache mit dem Scrum-Team initial erstellt.
• Ein für das Projekt repräsentativer Epic oder mehrere User Stories werden ausgewählt (Referenz-User-Stories).
• Mindestens zwei (2), aber maximal fünf (5) Sprints werden für die Ermittlung festgelegt.
• In der Sprintplanung bestimmen die Vertragspartner anhand der Referenz-User-Stories mit Hilfe von Story Points die Komplexität für den Sprint (Planning Poker). Planning Poker (auch als Scrum Poker bezeichnet) ist eine spielerische Team-Building-Aktivität zur Erreichung von Konsens in Bezug auf die Aufwandsschätzung innerhalb einer Gruppe von agilen Projekten. Zusätzlich wird eine Annahme bezüglich des Risikos bei der
• Implementierung sowie des Business-Values geschätzt. Daraus resultiert ein indikativer Festpreisrahmen, der noch nicht vertraglich bindend ist und erst in einem späteren Schritt (nämlich am Ende der Checkpoint-Phase) festgelegt wird.
• Die Erfahrung zeigt, dass zwischen 5 und maximal 15 User Stories pro Sprint bewältigt werden können (Sprintlänge[7]: 2 Wochen). Dies bedeutet, dass die User Stories sehr gut vorbereitet werden müssen.
• Die Sprint-Länge für die Test-Durchläufe sollte in der Checkpoint-Phase jeweils zwei (2) Wochen betragen. Dies deckt auch den zeitlichen Bedarf für das Sprint Planning, den Sprint Review sowie die Sprint Retrospektive ab.
• Der Aufwand für die Checkpoint-Phase wird nach Aufwand in Rechnung gestellt.
• Das Development Team wird aus unterschiedlichen Rollen der Innovations ON zusammengesetzt (die Rollen haben unterschiedliche Tagessätze[8]).
• Es wird eine Checkpoint-Phase (Testphase) festgelegt und mit der Umsetzung begonnen.

Hieraus werden empirische Erkenntnisse bezüglich der sog. Sprint Velocity gewonnen. Die Velocity ist der Durchschnitt über die Summen aller vom Team erledigten Story Points pro Sprint. Im Grunde zeigt die aktuelle Velocity die aktuelle Geschwindigkeit in der Umsetzung innerhalb eines Sprints an. Es gibt also eine aktuelle Velocity und eine durchschnittliche Velocity pro Sprint.Wir empfehlen eine Länge von mindestens zwei (2) und maximal fünf (5) Sprints mit einer Dauer der Sprints von zwei (2) Wochen (time-boxed). Es wird der arithmetische Mittelwert der Velocity der Sprints gebildet. Zusätzlich wird das arithmetische Mittel für die Kosten (Summe Tagessatz pro Rolle und Personentag) festgestellt.

Dadurch werden die Kosten pro Story Point für erfolgreich gelieferte Product Increments errechnet und mit zuvor getroffenen Annahmen überprüft und ggf. angepasst. Diese stellt die Baseline des Sprint-Festpreises dar. Abschließend wird der Festpreisrahmen vertraglich bindend festgelegt. Ebenso wird die Verteilung der Risiken vereinbart (In welchem Umfang werden entstandene Kosten bei Überschreitung des Maximalpreisrahmens an den Auftraggeber verrechnet? Erfolgt eine Incentivierung bei Unterschreitung der erwarteten Velocity?)

Nach jeweils vier (4) Sprints werden erneut die Velocity und der mittlere Aufwand (basierend auf den Innovations ON-internen Tagessätzen) kalkuliert. Die Abweichung zur Baseline wird bestimmt und ggf. eine Preisanpassung durchgeführt. Eine sinnvolle Erweiterung des Vertrages stellt die 60-40-20-Regelung dar, durch die eine gewisse Flexibilität in Form eines Kapazitätenpuffers hinzugefügt wird. Diese Regelung teilt den Backlog und den Projektumfang in eine 60%, 40% und 20% Prioritätenliste auf. Die Kategorie 60% bedeutet “Muss”, 40% bedeutet “Möchte” und 20% bedeutet “Stretch Goal”.

Die Elemente der Kategorie 60% sind auf alle Fälle zu liefern. Die Elemente der Kategorie 40% sind ebenfalls zu liefen, allerdings mit einem gewissen Verhandlungsspielraum (Tausch gegen andere im Rahmen des Change-Managements).

Die Summe der Elemente dieser beiden Kategorien stellen den “in-scope backlog” dar. Bei den Elementen der Kategorie 20% handelt es sich um Elemente, die dann bearbeitet werden, wenn der “in-scope backlog” frühzeitig fertiggestellt wurde.

Die Sprintlänge(n)

In der Regel und nach dem Scrum-Framework ist erst nach Durchlauf einiger Sprints feststellbar, welches eine optimale Sprintlänge ist. Als Grundlage kann man wählen: Je mehr Probleme es im Ablauf der Prozesse gibt, desto sinnvoller ist ein kürzerer Sprint-Zyklus. Insbesondere zu Beginn eines neuen Projektes (oder auch der Zusammenstellung eines neuen Scrum-Teams) beträgt die optimale Sprintlänge eine (1) Woche. Grundsätzlich kann die Länge der Sprints in der Sprint Retrospektive korrigiert werden.

Je genauer die User Stories definiert werden können, desto länger kann der Sprint ausfallen.

Das Scrum-Team

Letztendlich ist die Erfahrung des Scrum-Teams ausschlaggebend für die Festlegung der Sprintlänge - diese darf unter keinen Umständen von den Stakeholdern vorgegeben werden. Je erfahrener ein Scrum-Team ist, desto länger kann der Sprint sein.

Wichtiger Bestandteil zur Steuerung des Projektes ist die Benennung und Besetzung der projektverantwortlichen Rollen: Projektmanager und Product Owner sowie der Scrum Master. Aus diesen Rollen bildet sich der Lenkungskreis, der dafür Sorge trägt, dass der kontinuierliche Spezifikationsprozess funktioniert und die jeweils an den höchsten priorisierten Anforderungen als User Stories festgelegt werden. Das Scrum-Team besteht immer aus einem (Teilzeit)-Scrum Master, einem Product Owner und zwischen drei (3) und neun (9) Developern.

Eine wesentliche Voraussetzung für die erfolgreiche Lieferung der Produkte aus dem Product Backlog ist ein erfahrenes Scrum-Team. Wir gehen dabei von einer Erfahrung in der agilen Projektarbeit von mindestens zwei (2) Jahre für alle Projektmitglieder aus.

Der Scrum Master ist mitunter verantwortlich im Rahmen der Sprint Retrospektive die Notwendigkeit für Schulungsmaßnahmen (Scrum Framework) festzustellen und entsprechende Maßnahmen zu treffen. Letztendlich ist das Development Team eigenständig verantwortlich für die Mitteilung notwendiger Maßnahmen im Rahmen der Sprint Retrospektive.

Das Projektende

Bei agilen Festpreisprojekten gilt das Projekt als beendet, wenn der Auftraggeber den erwarteten Nutzen durch die bereits erfolgten Lieferungen als erfüllt abnimmt. Eine Verweigerung der Abnahme trotz Erreichen der zuvor gemeinsam definierten DoD (Definition of Done) sollte ausgeschlossen werden.

Offene Aufgaben aus dem Backlog den beendeten Sprints werden wieder in den Product Backlog übertragen. Im anschließenden Sprint Review wird erneut geprüft, für welche User Stories Aufgaben in den Sprint Backlog übertragen werden. Der Product Owner entscheidet über die Priorisierung der User Stories/Epics, aber auch darüber, ob User Stories dem Product Backlog neu hinzugefügt oder herausgenommen werden.

Eine vorzeitige Beendigung eines Sprints

Sollte ein (oder auch mehrere) bereits geplante(r) Sprint(s) vor deren Start abgesagt werden, so fällt in der Regel eine Pauschale (z.B. 20%) für den geplanten bzw. ausgefallenen Umsatz an (Cancellation Fee). Dabei muss eine vertragliche Vorlaufzeit für den Change Request festgelegt werden (z.B. 4 Wochen).

Änderung/Neuaufstellung des Entwicklungsteams

Muss das Entwicklungsteam aufgrund neuer oder geänderter Anforderungen im Product Backlog neu aufgestellt oder angepasst werden (neue, ungeplante Anforderung wie z.B. Spezialwissen), so muss auch dies mit einer entsprechenden Vorlaufzeit bedacht werden. Tritt durch eine schlechte Planung des Backlog oder zu spät aufgesetzte Change Requests eine Minderauslastungen des Entwicklungsteams ein, so sollte dies dem Vertragspartner in Rechnung gestellt werden.