Definition von „Fertig“ (DoD): Checkliste und Beispiele

Die Definition von „fertig“ (DoD) ist die kurze Checkliste, auf die sich ein Team einigt und die jede Story erfüllen muss, bevor sie als abgeschlossen gilt: geprüft, getestet, zusammengeführt, bereitgestellt, abgenommen. Sie stellt einen einheitlichen Standard für das gesamte Team dar. 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.

Was die Definition von „fertig“ in Scrum bedeutet

Der Scrum Guide bezeichnet dies als „eine formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätskriterien erfüllt“. Einfach ausgedrückt ist die Definition von „Fertig“ die Verpflichtung, die mit dem Inkrement, einem der drei Scrum-Artefakte, verbunden ist. Arbeit, die diese Definition erfüllt, wird Teil des Inkrements. Arbeiten, die diese Anforderungen nicht erfüllen, können weder veröffentlicht noch bei der Sprint-Review präsentiert werden; sie werden zurück ins Product Backlog verschoben.

Falls Ihre Organisation bereits eine „Definition of Done“ festgelegt hat, dient diese jedem Team als Mindeststandard, den es ergänzen kann. Ist dies nicht der Fall, erstellt das Team eine eigene. Dieser Ansatz ist nicht auf Scrum beschränkt: Kanban-Teams erstellen häufig dieselbe Liste als Richtlinie für die Verschiebung von Aufgaben in ihre letzte Spalte.

Beispiele für die Definition von „fertig“

Beispiel für eine „Definition of Done“-Checkliste: ein Software-Team

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

• Die Abnahmekriterien wurden erfüllt und überprüft.
• Der Code wurde geprü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 so an, dass es den tatsächlichen Anforderungen Ihres Teams entspricht. Eine Definition von „fertig“, die eine Zeile enthält, die niemand überprüft, ist schlechter 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.

Beispiel für die Definition von „fertig“: Ein Team, das keinen Code veröffentlicht

Das gleiche Prinzip gilt auch für ein Marketing-, Content- oder Design-Team. Die Definition von „fertig“ eines Content-Teams könnte wie folgt lauten:

• Die Akzeptanzkriterien des Lastenhefts sind erfüllt.
• Von einer anderen Person als dem Autor bearbeitet.
• Fakten, Zahlen und Links wurden überprüft.
• Grundlagen der Barrierefreiheit sind erfüllt: Alternativtext, Reihenfolge der Überschriften, ausreichender Kontrast.
• Genehmigt von der Person, die den Antrag gestellt hat.
• Veröffentlicht oder weitergeleitet und an einer für das Team einsehbaren Stelle festgehalten.

Story-, Sprint- und Release-Ebenen

Scrum verlangt eine einheitliche Definition dessen, was als „fertig“ gilt, für das Inkrement. In der Praxis gruppieren viele Teams die Prüfungen danach, wo sie naturgemäß stattfinden:

Stufe	Gilt für	Typische Artikel
Geschichte	Jedes Backlog-Element	Code geprüft, Tests bestanden, Akzeptanzkriterien erfüllt, vom Product Owner abgenommen
Sprint	Das Inkrement als Ganzes	In den Hauptzweig integriert, Regressionssuite erfolgreich, auf Staging bereitgestellt
Veröffentlichung	Was die Kunden erreicht	Versionshinweise verfasst, Sicherheits- und Leistungsprüfungen durchgeführt, Support informiert

Behalten Sie die Story-Ebene als Kernliste bei. Falls eine Überprüfung erst bei der Veröffentlichung erfolgen kann, vermerken Sie dies ebenfalls auf der Liste, damit niemand eine Story als erledigt markiert, in der Annahme, dass jemand anderes diese Lücke später bemerken wird.

So verfassen Sie eine „Definition of Done“

1. Beginnen Sie mit dem, was Ihnen immer wieder entgeht. Betrachten Sie die letzten Sprints: die Fehler, die erst nach dem „Fertig“-Status entdeckt wurden, die zurückgewiesenen Stories, die übertragenen Aufgaben. Jeder einzelne Punkt weist auf eine Lücke hin.
2. Erstellen Sie diese gemeinsam mit dem gesamten Team. Die Mitarbeiter, die die Arbeit ausführen, einigen sich in einer Sitzung darauf, wobei der Scrum-Master die Moderation übernimmt und der Product Owner anwesend ist. Eine von außen vorgegebene Liste wird das Team unter Termindruck nicht verteidigen.
3. Stellen Sie sicher, dass jede Zeile überprüfbar ist. „Getestet“ ist eine Einschätzung; „automatisierte Tests, die in der CI geschrieben wurden und erfolgreich durchlaufen wurden“ ist eine Überprüfung. Sollten zwei Personen unterschiedlicher Meinung darüber sein, ob eine Zeile erfüllt ist, formulieren Sie diese neu.
4. Beschränken Sie sich auf das, was Sie derzeit umsetzen werden. Wir würden mit fünf bis acht Zeilen beginnen. Fügen Sie die ambitionierten Ziele hinzu, sobald das Team diese tatsächlich erreichen kann.
5. Platzieren Sie sie dort, wo die Arbeit stattfindet. Eine Checkliste in der Ticketvorlage oder in der Spalte „Erledigt“ des Boards wird genutzt. Eine Seite im Wiki gerät in Vergessenheit.
6. Überprüfen Sie dies in der Retrospektive. Wenn dieselbe Lücke zweimal übersehen wird, fügen Sie eine Zeile hinzu. Wenn eine Zeile abgehakt wird, ohne dass jemand sie überprüft hat, fragen Sie, ob sie ihren Platz noch verdient.

Definition von „fertig“ im Vergleich zu Abnahmekriterien

Dies ist der Unterschied, über den Teams am häufigsten stolpern. 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. Die 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 zur 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“ leitet eine Story in den Sprint ein: klein genug, klar genug, geschätzt. Die Definition von „fertig“ leitet die abgeschlossene Arbeit aus dem Sprint heraus. Bei „bereit“ geht es um die Story; bei „fertig“ geht es um die Arbeit. Teams, die nur einen dieser Zustände kennen, haben in der Regel „Bereit“ (da unvorbereitete Stories lautstark bemerkt werden) und lassen „Fertig“ stillschweigend verfallen – so häufen sich Überträge und „zu 90 % abgeschlossene“ Stories an.

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	Lokales, dieser Bericht	Weltweit, jede Geschichte
Gates	Start im Sprint	Der Ausgang der Geschichte selbst	Beenden des Sprints
Antworten	„Können wir damit beginnen?“	„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 Anforderungen; 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 definierter Begriff von „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.

Wie die Definition von „fertig“ Ihre Schätzungen beeinflusst

Story-Punkte bemessen den Arbeitsaufwand bis zur vollständigen Fertigstellung, nicht bis zum „Abschluss der Programmierung“. Die Definition von „fertig“ ist somit in jeder Schätzung bereits berücksichtigt. Fügen Sie eine Zeile wie „Leistungstests durchgeführt“ hinzu, und jede Story wird ein wenig umfangreicher. Wenn sich die Liste ändert, überprüfen Sie Ihre Referenz-Stories in der nächsten Planungssitzung erneut, da sonst die Velocity aus einem Grund sinkt, den niemand benennen kann.

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, bläht sich die Velocity auf: Das Team verbucht Punkte für Arbeit, die eigentlich nicht auslieferungsfähig ist, und die Prognose verliert still und leise jede Bedeutung.

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 Abnahmekriterien 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 Umfeld?

Die Definition von „fertig“ (DoD) ist eine einheitliche 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 für jede einzelne 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 und gilt für jede Story gleichermaßen. Die Akzeptanzkriterien sind lokal und beziehen sich speziell auf eine einzelne Story. Die Akzeptanzkriterien legen fest, was diese Funktion leisten muss; die Definition von „fertig“ legt fest, was „auslieferungsfähig“ 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 der 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.

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

Die „Ready“-Kriterien markieren den Einstieg in den Sprint – sie stellen die Hürde dar, die eine Story überwinden muss, bevor sich das Team darauf festlegt. Die „Done“-Kriterien markieren den Ausstieg – sie stellen die Hürde dar, die die abgeschlossene Arbeit überwinden 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.

Wie formuliert man eine Definition des Fertigstellungszustands?

Beginnen Sie mit dem, was Ihnen immer wieder entgeht: den Fehlern, den Nacharbeiten und den Überhängen aus den letzten Sprints. Einigen Sie sich als gesamtes Team auf die Liste, formulieren Sie jede Zeile so, dass sie mit „Ja“ oder „Nein“ beantwortet werden kann, beschränken Sie sie auf das, was Sie tatsächlich durchsetzen werden, und fügen Sie sie dort ein, wo die Arbeit stattfindet, beispielsweise in die Ticketvorlage. Gehen Sie die Liste dann in der Retrospektive erneut durch, wann immer etwas durch die Maschen rutscht.

Wer legt die Definition von „fertig“ fest?

Das Entwicklungsteam trägt die Verantwortung dafür, in der Regel unter der Leitung des Scrum-Masters. Der Product Owner hat Einfluss auf die Akzeptanzkriterien, doch die Mitarbeiter, die die Arbeit ausführen, entscheiden, was „fertig“ aus technischer Sicht bedeutet, da sie diejenigen sind, 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 der Sprintstrecke.
• Fehler beim Planning Poker: Wie ein vager „fertig“-Status die Velocity in die Höhe treibt.