Definition von „fertig“

Die Definition von „fertig“ ist eine Checkliste für das gesamte Team – der Standard, den jede Story erfüllen muss, bevor sie als abgeschlossen gilt. Akzeptanzkriterien gelten pro Story; die Definition von „fertig“ ist allgemein gültig. Wenn man diese beiden Begriffe verwechselt, führt dies dazu, dass „fertig“ stillschweigend die Bedeutung „funktioniert auf meinem Rechner“ annimmt.

Jedes Team hat schon einmal die Kluft zwischen „Der Entwickler sagt, es sei fertig“ und „Es ist tatsächlich bereit für die Auslieferung“ gespürt. Die Definition von „Fertig“ schließt diese Lücke. Man einigt sich einmal darauf und setzt sie in jedem Sprint durch, unabhängig davon, was eine einzelne Story beinhaltet. Ohne diese Definition ist „fertig“ eine individuelle Einschätzung – und der Unterschied zeigt sich bei der Demo oder, schlimmer noch, in der Produktion.

Eine Checkliste zur Definition des Fertigstellungszustands (Beispiel)

Ein praktikabler Ausgangspunkt für ein Team, das eine Webanwendung bereitstellt:

• Die Abnahmekriterien wurden erfüllt und überprüft.
• Der Code wurde überprüft und in den Hauptzweig integriert.
• Automatisierte Tests wurden geschrieben und bestanden; es gibt keine neuen unzuverlässigen Tests.
• Es sind keine Regressionen oder offenen kritischen Fehler im Zusammenhang mit diesem Feature bekannt.
• Die Dokumentation und das Änderungsprotokoll wurden aktualisiert, sofern die Änderung für die Benutzer relevant ist.
• In die Staging-Umgebung bereitgestellt und einem Smoke-Test unterzogen.
• Der Product Owner hat dies akzeptiert.

Übernehmen Sie dies und passen Sie es dann an das an, was Ihr Team tatsächlich umsetzen wird. Eine Definition von „fertig“, bei der eine bestimmte Zeile von niemandem überprüft wird, ist schlimmer als eine kurze – sie führt dazu, dass das Team die gesamte Liste als reine Dekoration betrachtet. Beschränken Sie sich auf einen Bildschirm, und sorgen Sie dafür, dass jeder Punkt überprüfbar ist.

Definition von „fertig“ im Vergleich zu Abnahmekriterien

Dies ist die Unterscheidung, an der Teams am häufigsten scheitern. Die Akzeptanzkriterien für eine Anmelde-Story beziehen sich speziell auf die Anmeldung – bei korrekten Anmeldedaten gelangen Sie zum Dashboard, nach drei falschen Versuchen wird das Konto gesperrt. Die Definition von „fertig“ – geprüft, getestet, bereitgestellt – ist für die Anmelde-Story, die Such-Story und die Abrechnungs-Story identisch. Kriterien sind lokal und beantworten die Frage: „Haben wir das Richtige entwickelt?“ Die Definition von „fertig“ ist global und beantwortet die Frage: „Ist irgendein Teil unserer Arbeit jemals bereit für die Auslieferung?“ Eine Story ist erst dann fertig, wenn sie beide Hürden genommen hat.

Definition von „bereit“ im Vergleich zur Definition von „fertig“

Es handelt sich um Buchstützen, nicht um symmetrische Zwillinge. Die Definition von „bereit“ regelt den Eintritt einer Story in den Sprint – klein genug, klar genug, geschätzt. Die Definition von „fertig“ regelt den Austritt der abgeschlossenen Arbeit aus dem Sprint. Bei „bereit“ geht es um die Story; bei „fertig“ geht es um die Arbeit. Teams, die nur eine dieser Definitionen anwenden, nutzen in der Regel „Ready“ (da unvorbereitete Stories lautstark bemerkt werden) und lassen „Done“ stillschweigend vernachlässigen – wodurch sich Überträge und „zu 90 % abgeschlossene“ Stories ansammeln.

Die drei Checklisten lassen sich klar voneinander unterscheiden, sobald Sie erkennen, was jeweils durch sie geregelt wird:

	Definition von „bereit“	Abnahmekriterien	Definition von „fertig“
Geltungsbereich	Weltweit – jede Geschichte	Lokal – dieser Bericht	Weltweit – jede Geschichte
Gates	Start im Sprint	Der Ausgang der Geschichte selbst	Beenden des Sprints
Antworten	„Können wir damit anfangen?“	„Haben wir das Richtige geschaffen?“	„Ist es versandfertig?“
Im Besitz von	Team, gemeinsam mit dem Product Owner	Produktverantwortlicher, gemeinsam mit dem Team	Das Team

Wer legt fest, was „fertig“ bedeutet?

Das Team formuliert die Kriterien; das Team sorgt für deren Einhaltung. Der Scrum-Master moderiert, und der Product Owner hat Einfluss auf die Akzeptanzkriterien, doch die Entwickler entscheiden, was „fertig“ aus technischer Sicht erfordert – denn ein vage definiertes „fertig“ ist eine Schuld, die sie begleichen müssen, nicht das Management. Gehen Sie dies in einer Retrospektive erneut durch, wenn dieselbe Lücke immer wieder auftritt; das ist das Signal dafür, dass eine Grenze fehlt.

Was läuft schief?

Die Definition von „fertig“ wird zu einem Plakat. Sie wird im Team-Wiki ausgehängt, bei der Einarbeitung vorgetragen und unter Termindruck ignoriert – „die Tests schreiben wir im nächsten Sprint.“ Zwei Sprints später ist die Testschuld strukturell verankert und die Definition reine Fiktion. Wenn „fertig“ vage definiert ist, steigt die Velocity: Das Team verbucht Punkte für Arbeit, die eigentlich nicht auslieferungsfähig ist, und die Prognose verliert still und leise jede Aussagekraft.

Die Lösung liegt nicht in einer längeren Liste, sondern in einer kürzeren, an der das Team festhalten wird. Eine Definition von „fertig“ ist nur so real wie die Aufgabe, die Sie bereit sind, nicht als fertig zu markieren, weil sie einen dieser Punkte nicht erfüllt hat.

Die Akzeptanzkriterien bilden die Kontrollschwelle für die Story. Die Definition von „fertig“ bildet die Kontrollschwelle für das Team. Halten Sie diese so kurz, dass Sie sie auch tatsächlich durchsetzen können – eine nicht durchgesetzte Kontrollschwelle ist bloß Papierkram.

Häufig gestellte Fragen

Wie lautet die Definition von „fertig“ im agilen Ansatz?

Die Definition von „fertig“ ist eine einzige Checkliste, die jede Story erfüllen muss, bevor sie als abgeschlossen gilt – in der Regel getestet, einer Code-Prüfung unterzogen, zusammengeführt, dokumentiert und in die Staging-Umgebung bereitgestellt. Es handelt sich um einen gemeinsamen Standard für das gesamte Team, nicht um eine Liste pro Story, und er dient dazu, dass „fertig“ jedes Mal dasselbe bedeutet, wenn jemand diesen Begriff verwendet.

Worin besteht der Unterschied zwischen der Definition von „fertig“ und den Abnahmekriterien?

Die Definition von „fertig“ ist global – für jede Story gilt dieselbe Schwelle. Die Akzeptanzkriterien sind lokal – sie beziehen sich auf eine bestimmte Story. Die Akzeptanzkriterien legen fest, was diese Funktion leisten muss; die Definition von „fertig“ legt fest, was „veröffentlichungsreif“ für jede vom Team erbrachte Arbeit bedeutet. Eine Story muss beide Kriterien erfüllen.

Was ist eine „Definition of Done“-Checkliste?

Eine kurze, präzise Liste von Bedingungen, die für jede Story gelten: Code geprüft und zusammengeführt, Tests geschrieben und bestanden, keine bekannten Regressionen, Dokumentation aktualisiert, in einer Testumgebung bereitgestellt und vom Product Owner akzeptiert. Die genauen Punkte variieren je nach Team, doch die Liste sollte auf einen Bildschirm passen und jede Zeile sollte überprüfbar sein.

Was ist der Unterschied zwischen der Definition von „bereit“ und der Definition von „fertig“?

Die „Ready“-Prüfung markiert den Einstieg in den Sprint – die Hürde, die eine Story nehmen muss, bevor sich das Team darauf festlegt. Die „Done“-Prüfung markiert den Ausstieg – die Hürde, die die abgeschlossene Arbeit nehmen muss, bevor sie ausgeliefert wird. Bei „Ready“ geht es darum, dass die Story gut strukturiert ist; bei „Done“ geht es darum, dass die Arbeit zur Auslieferung bereit ist.

Wer legt die Definition von „fertig“ fest?

Die Verantwortung dafür liegt beim Entwicklungsteam, wobei in der Regel der Scrum-Master die Rolle des Moderators übernimmt. Der Product Owner hat Einfluss auf die Akzeptanzkriterien, doch diejenigen, die die Arbeit ausführen, entscheiden, was „fertig“ aus technischer Sicht bedeutet – denn sie sind es, die den Preis dafür zahlen, wenn dieser Begriff zu vage definiert wird.

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden – hier finden Sie alles zum Thema.
• Akzeptanzkriterien – der Test auf Story-Ebene, mit dem die Definition von „fertig“ häufig verwechselt wird.
• Definition von „ready“ – das Zieltor am anderen Ende des Sprints.
• Fehler beim Planning Poker – wie ein vager „fertig“-Status die Velocity in die Höhe treibt.