Definition of Done: Beispiele und wie man sie schreibt

Die Definition of Done (DoD) ist eines jener Konzepte, das selbstverständlich klingt, bis Ihr Team etwas ausliefert, das in der Produktion kaputt geht, eine Überprüfung verpasst oder nie dokumentiert wurde. Dann wird es dringend.

Was ist eine Definition of Done (DoD)?

Eine Definition of Done ist eine gemeinsam vereinbarte Checkliste von Kriterien, die eine Arbeitseinheit erfüllen muss, bevor das Team sie als vollständig betrachtet. Nicht "größtenteils fertig". Nicht "bei mir funktioniert es". Tatsächlich fertig.

Die DoD gilt für jede Arbeitseinheit auf derselben Ebene, für jede User Story, jeden Sprint, jedes Release. Sie wird nicht von einer Person geschrieben und anderen vorgelegt. Sie wird gemeinsam vom Team erstellt, irgendwo sichtbar aufgehängt und konsequent durchgesetzt. Wenn Arbeit jeden Punkt der Liste erfüllt, ist sie fertig. Wenn nicht, ist sie es nicht.

Kennzahlen: Definition of Done

• Teams mit einer klar dokumentierten DoD liefern laut einer im Empirical Software Engineering Journal (2018) veröffentlichten Studie 28 % weniger Defekte als Teams ohne eine solche.
• Der State of Agile Report 2023 (digital.ai) stellte fest, dass inkonsistente Praktiken und unklare Standards zu den fünf häufigsten Gründen für das Scheitern agiler Transformationen gehören. Die DoD adressiert beide direkt.
• Eine Studie von Capers Jones ergab, dass die Behebung eines Defekts in der Produktion 10 bis 100 Mal mehr kostet als das Erkennen während der Entwicklung; eine DoD, die Test- und Review-Anforderungen enthält, ist eines der kostengünstigsten verfügbaren Defektpräventions-Tools.

Definition of Done vs. Akzeptanzkriterien

Diese beiden Begriffe werden ständig verwechselt, und die Verwechslung verursacht echte Probleme. Sie hängen zusammen, decken aber unterschiedliches Terrain ab.

Akzeptanzkriterien beantworten: Tut dieses Feature, was es soll? Die DoD beantwortet: Hat das Team alles getan, was erforderlich ist, um dieses Increment als auslieferbar zu bezeichnen?

Eine Story kann alle ihre Akzeptanzkriterien erfüllen und die DoD dennoch nicht bestehen, wenn beispielsweise die Dokumentation nicht aktualisiert oder der Code nicht reviewed wurde. Beide Gates müssen passiert werden.

Einige Teams nutzen auch eine Definition of Ready (DoR) auf der Eingabeseite, eine Checkliste der Bedingungen, die eine Arbeitseinheit erfüllen muss, bevor das Team sie in einen Sprint zieht. Die DoD schließt die Schleife auf der Ausgabeseite. Zusammen schaffen sie eine Qualitätsgrenze um den gesamten Sprint-Zyklus. Siehe Backlog-Verfeinerung, wie die DoR in die Sprint-Vorbereitung passt.

Warum eine Definition of Done wichtig ist

Ohne DoD bedeutet "fertig" für jede Person im Team etwas anderes. Ein Entwickler betrachtet ein Feature als fertig, wenn der Code kompiliert. Der QA-Ingenieur betrachtet es als fertig, wenn Tests bestehen. Der Tech Lead betrachtet es als fertig, wenn es code-reviewed ist. Der Product Owner betrachtet es als fertig, wenn es deployed ist. Keiner liegt falsch. Aber wenn sie sich nie auf einen einzigen Standard einigen, wird das Team weiterhin Arbeit ausliefern, die auf Weisen unvollständig ist, die niemand vorhergesehen hat.

So sieht es in der Praxis aus. Ein Team ohne DoD:

• Liefert Code, der lokal funktioniert, aber in der Staging-Umgebung scheitert, weil Umgebungsprüfungen nicht Teil der mentalen Checkliste irgendjemandes waren
• Merged Arbeit, die vom Autor selbst "reviewed" wurde
• Häuft Dokumentations-Schulden an, weil niemand es als Anforderung aufgeschrieben hat
• Verbringt die Hälfte der Sprint-Retrospektive damit zu diskutieren, was "fertig" tatsächlich für die gerade abgeschlossenen Stories bedeutet

Ein Team mit DoD:

• Hat einen gemeinsamen, nicht verhandelbaren Standard, der nicht von individueller Interpretation abhängt
• Erkennt Lücken während des Sprints, nicht nach dem Deployment
• Reduziert Nacharbeit, weil alle die Exitkriterien kennen, bevor sie beginnen
• Arbeitet schneller, weil es beim Sprint-Review weniger Überraschungen gibt

Die DoD schützt auch den Product Backlog vor falschen Abschlüssen. Wenn eine Story als fertig markiert wird, ohne alle Kriterien zu erfüllen, wird die eigentliche Arbeit, die Korrekturen, das Review, die Dokumentation, irgendwo im Backlog vergraben und taucht später als ungeplante Arbeit wieder auf.

Ebenen von "Fertig"

Die meisten Teams arbeiten mit drei Ebenen von "Fertig". Jede Ebene hat ihre eigene Checkliste, und eine höherstufige Checkliste enthält typischerweise alles aus der darunter.

Story-Level-Fertig

Das ist die Checkliste für einzelne User Stories oder Aufgaben. Sie deckt die spezifische Arbeit ab, die erforderlich ist, um ein Increment zu liefern:

• Code geschrieben und self-reviewed
• Unit-Tests geschrieben und bestanden
• Code von mindestens einem anderen Teammitglied reviewed
• Akzeptanzkriterien erfüllt und verifiziert
• Feature-Branch in main gemergt (oder dem vereinbarten Integrations-Branch)

Sprint-Level-Fertig

Diese Checkliste gilt für das gesamte Sprint-Increment, die Summe aller im Sprint abgeschlossenen Stories. Sie fügt oft Integrations- und Deployment-Kriterien hinzu:

• Alle Story-Level-DoD-Punkte für jede im Sprint enthaltene Story erfüllt
• Integrationstests gegen den vollständigen Build bestanden
• In der Staging-Umgebung deployed
• Sprint-Ziel erreicht oder explizit bewertet
• Release-Notes oder Changelog aktualisiert

Release-Level-Fertig

Das deckt alles ab, was erforderlich ist, bevor das Increment zu Produktionsnutzern gelangt. Hier leben typischerweise Compliance-, Performance- und Abnahmekriterien:

• End-to-End-Tests in einer produktionsnahen Umgebung bestanden
• Performance-Benchmarks erfüllt (Ladezeit, Fehlerrate usw.)
• Security-Scan abgeschlossen ohne kritische Befunde
• Dokumentation aktualisiert und veröffentlicht
• Stakeholder-Abnahme erhalten
• Rollback-Plan dokumentiert

Teams, die in der Sprint-Planung arbeiten, sollten klarstellen, welche "Fertig"-Ebene für das Output des jeweiligen Sprints gilt. Nicht jeder Sprint endet in einem Produktions-Release, aber das Team sollte genau wissen, wo die Messlatte liegt, bevor es beginnt.

Beispiele für Definitionen of Done

Hier sind konkrete DoD-Checklisten für drei häufige Teamtypen. Dies sind keine Vorlagen zum wörtlichen Kopieren, sondern Ausgangspunkte. Die DoD Ihres Teams sollte Ihre tatsächlichen Standards, Werkzeuge und Ihren Workflow widerspiegeln.

Software-Entwicklungsteam (Story-Level)

• Code geschrieben und kompiliert fehlerfrei
• Unit-Tests für neue Logik geschrieben, mit mindestens 80 % Abdeckung der geänderten Dateien
• Code reviewed und von mindestens einem anderen Entwickler genehmigt
• Alle automatisierten Tests in der CI-Pipeline bestanden
• Keine neuen Linting-Fehler eingeführt
• Feature in der Staging-Umgebung deployed und smoke-getestet
• Akzeptanzkriterien vom Entwickler oder QA verifiziert
• Alle neuen APIs oder Konfigurationsänderungen im Team-Wiki dokumentiert
• Feature-Flag oder Toggle vorhanden, wenn die Arbeit nicht bereit für den vollständigen Rollout ist

Marketing- und Content-Team (Story-Level)

• Inhalt gemäß vereinbarter Wortzahl und Tonrichtlinien geschrieben
• Von einem zweiten Autor oder Redakteur auf Genauigkeit und Brand Voice überprüft
• SEO-Checkliste abgeschlossen (Title Tag, Meta-Description, Ziel-Keyword in H1)
• Alle internen Links verifiziert und funktionsfähig
• Bilder optimiert und Alt-Text hinzugefügt
• Gemäß Content-Kalender im CMS geplant oder veröffentlicht
• Distributions-Aufgaben abgeschlossen (Social Posts geplant, Newsletter-Aufnahme bestätigt)
• Analytics-Tracking bestätigt (UTM-Parameter, Event-Tags vorhanden)

Design-Team (Story-Level)

• Design entspricht dem genehmigten Brief oder den User-Story-Anforderungen
• Vom Lead Designer und relevanten Stakeholdern reviewed
• Barrierefreiheits-Richtlinien geprüft (Farbkontrast, Schriftgröße, Tastaturfluss für interaktive Elemente)
• Alle Zustände dokumentiert: Standard, Hover, Fokus, Fehler, Leer, Laden
• Assets in erforderlichen Formaten exportiert und in die gemeinsame Design-Bibliothek hochgeladen
• Übergabe-Notizen für das Entwicklungsteam geschrieben
• Offenes Feedback aus dem Review gelöst oder explizit mit Begründung verschoben

So schreiben Sie eine Definition of Done

Schritt 1: Das Team zusammenbringen

Die DoD funktioniert nur, wenn alle daran glauben. Das bedeutet, sie gemeinsam zu erstellen: Entwickler, Designer, QA, Product Owner, alle, die die Arbeit erledigen. Ein 60-minütiger Workshop ist in der Regel genug für eine erste Version. Lassen Sie den Scrum Master oder Team Lead sie nicht alleine schreiben und dann zur "Genehmigung" vorlegen. Die gemeinsame Erstellung ist der Punkt.

Schritt 2: Auflisten, was Fertigstellung wirklich erfordert

Beginnen Sie, indem Sie das Team fragen: "Denken Sie an das letzte Stück Arbeit, das Sie ausgeliefert haben und das mit einem Problem zurückkam. Welcher Schritt wurde übersprungen?" Arbeiten Sie von Fehlern rückwärts, um die Checklisten-Punkte zu finden, die wirklich wichtig sind. Dann vorwärts arbeiten: Wie sieht Gut aus, wenn wir ausliefern? Was würde uns in Verlegenheit bringen, wenn wir es vergessen?

Gruppieren Sie Punkte in Kategorien: Code-Qualität, Tests, Dokumentation, Deployment, Review. Das macht die DoD beim Sprint einfacher zu überblicken.

Schritt 3: Jeden Punkt überprüfbar halten

Jeder DoD-Punkt sollte verifizierbar sein: entweder ist er erledigt oder er ist es nicht. "Code-Qualität ist gut" ist kein DoD-Punkt. "Code reviewed und von mindestens einem anderen Teammitglied als dem Autor genehmigt" ist einer. Der Test: Können Sie auf Nachweise verweisen, dass dieser Punkt erfüllt wurde? Wenn ja, gehört er auf die DoD. Wenn er Urteilsvermögen erfordert, wandeln Sie ihn in eine Richtlinie um oder formulieren Sie ihn in spezifischere Kriterien um.

Schritt 4: Vereinbaren und sichtbar aushängen

Sobald das Team einen Entwurf hat, holen Sie explizites Einverständnis ein. Nicht "keine Einwände", sondern echtes Buy-in. Hängen Sie die DoD irgendwo auf, wo das gesamte Team sie täglich sieht: das Sprint-Board, das Team-Wiki, die Kanal-Beschreibung in Slack. Sie sollte kein Dokument in einem Ordner sein, den niemand öffnet. Wenn das Team sie nicht sehen kann, wird sie nicht genutzt.

Schritt 5: Überprüfen und weiterentwickeln

Die DoD ist nicht dauerhaft. Sie sollte in der Sprint-Retrospektive überprüft werden, wann immer das Team etwas ausliefert, das eine Lücke aufgedeckt hat. Wenn das Team ein neues Tool hinzufügt (z. B. einen automatisierten Security-Scanner), fügen Sie es zur DoD hinzu. Wenn ein Checklisten-Punkt so selbstverständlich geworden ist, dass ihn niemand mehr überspringt, überlegen Sie, ob er noch aufgeschrieben werden muss oder ob er jetzt eine Team-Gewohnheit ist.

Eine DoD, die sich nie ändert, ist entweder perfekt (unwahrscheinlich) oder wird ignoriert (wahrscheinlicher).

Häufige Fehler

Sie zu lang machen. Eine 30-Punkte-DoD wird nicht genutzt. Zielen Sie auf 8 bis 12 Punkte, die Ihre echten Qualitätslücken abdecken, keine erschöpfende Idealvorstellung. Wenn Sie die DoD nach einer Woche nicht auswendig kennen, ist sie zu lang.

Sie auf Organisations- statt Team-Ebene schreiben. Eine DoD, die von der Führung vorgegeben wird, deckt Richtlinie ab, nicht Praxis. Jedes Team braucht eine DoD, die seinen tatsächlichen Workflow, seine Werkzeuge und Standards widerspiegelt.

Als Wunschvorstellung behandeln. Wenn das Team nicht realistisch jeden DoD-Punkt in einem normalen Sprint erfüllen kann, ist die DoD Wunschvorstellung, nicht operativ. Kürzen Sie sie auf das zurück, wozu das Team sich wirklich verpflichten kann, und heben Sie dann die Messlatte schrittweise an, wenn Kapazität und Werkzeuge sich verbessern.

Beim Endspurt überspringen. "Wir überspringen die Dokumentation in diesem Sprint, weil wir zeitlich knapp sind" ist der Moment, in dem die DoD aufhört, irgendetwas zu bedeuten. Teilweise Ausnahmen häufen sich zu konsequenten Ausnahmen. Wenn die DoD unter Druck ausgesetzt werden kann, war sie nie ein echter Standard.

Nicht-funktionale Anforderungen vergessen. Funktionales Verhalten wird von Akzeptanzkriterien abgedeckt. Die DoD ist der Ort, wo Performance-, Sicherheits-, Barrierefreiheits- und Dokumentationsstandards leben. Teams, die diese aus der DoD herauslassen, liefern Features aus, die funktionieren, aber das System über die Zeit verschlechtern.

Häufig gestellte Fragen

Wer besitzt die Definition of Done?

Das Team besitzt sie kollektiv. Der Product Owner kann sie beeinflussen (er sorgt sich um Auslieferbarkeit), und der Scrum Master kann ihre Erstellung und Überprüfung moderieren. Aber in Scrum sind es die Developers, die sich verpflichten, die DoD für jedes Increment zu erfüllen. Niemand kann sie einseitig mitten im Sprint ändern.

Was ist der Unterschied zwischen einer Definition of Done und einer Checkliste?

Eine DoD ist eine Art Checkliste, aber eine mit einem spezifischen Zweck und einem spezifischen Vertrag dahinter. Eine Checkliste ist ein Werkzeug. Die DoD ist eine Vereinbarung, dass jedes Increment diese Messlatte überschreiten muss, bevor das Team es als fertig bezeichnet. Der Unterschied ist wichtig, weil er gemeinsame Verantwortung und Konsequenzen impliziert: Arbeit, die die DoD nicht erfüllt, wird nicht auf das Sprint-Ziel angerechnet.

Braucht jedes Team eine Definition of Done?

Ja, wenn das Team Arbeit ausliefert, von der andere abhängen. Die DoD ist der Mechanismus, der "fertig" für alle zur gleichen Bedeutung macht. Teams ohne eine entwickeln entweder implizite Standards (die nicht geteilt oder durchgesetzt werden) oder streiten sich zum ungünstigsten Zeitpunkt über Fertigstellung, meist am Ende eines Sprints.

Kann die Definition of Done für verschiedene Arbeitsarten unterschiedlich sein?

Ja, mit Vorsicht. Viele Teams haben eine Story-Level-DoD und eine Sprint-Level-DoD (wie im Ebenen-Abschnitt oben beschrieben). Einige Teams haben leicht unterschiedliche Kriterien für Bug-Fixes vs. neue Features. Aber Vorsicht vor Fragmentierung. Je mehr Ausnahmen und Sonderfälle die DoD hat, desto mehr kognitiven Aufwand schafft sie und desto weniger zuverlässig wird sie angewendet.

Wie hängt die Definition of Done mit Story Points zusammen?

Story Points schätzen den relativen Aufwand. Die DoD definiert Qualitätsstandards. Sie hängen zusammen, weil die DoD in Schätzungen einbezogen werden sollte: Wenn das Erfüllen der DoD für eine Story 3 extra Stunden dauert, sollte diese Zeit in der Story-Point-Schätzung widergespiegelt werden, nicht als Overhead behandelt werden, der beim Zeitdruck übersprungen wird. Wenn Teams Stories unterschätzen, weil sie DoD-Anforderungen nicht berücksichtigen, geraten sie genau in die Art von Zeitdruck, der zu DoD-Abkürzungen führt.

---

Eine gut ausgearbeitete Definition of Done verlangsamt ein Team nicht. Sie beseitigt die Unklarheit, die Teams verlangsamt. Wenn alle genau wissen, was "fertig" bedeutet, bevor sie beginnen, gibt es weniger Überraschungen, weniger Nacharbeitsschleifen und weniger Diskussionen beim Sprint-Review. Beginnen Sie mit etwas Einfachem, setzen Sie es konsequent durch, und lassen Sie es sich mit dem Team weiterentwickeln.

Weiterführende Lektüre

• Product Backlog
• Backlog-Verfeinerung
• User Stories
• Story Points
• Sprint-Retrospektive
• Sprint-Planung
• Was ist Scrum?