logo
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Die Definition of Done Checkliste, die dein Team wirklich braucht

Agiles Team steht um ein Whiteboard mit einer abgehakten Checkliste und gibt sich High-Fives nach Abschluss eines Sprint-InkrementsAgiles Team steht um ein Whiteboard mit einer abgehakten Checkliste und gibt sich High-Fives nach Abschluss eines Sprint-Inkrements Jedes Scrum-Team erlebt den Moment, in dem jemand eine Story als "fertig" markiert und jemand anderes fragt: "Aber hast du die Tests geschrieben?" Diese Lücke zwischen dem, was eine Person als abgeschlossen betrachtet, und dem, was das Team tatsächlich braucht, ist genau das, was eine Definition of Done löst. Der Scrum Guide 2020 hat die DoD von einem Nice-to-have zu einer formalen Verpflichtung erhoben, die an das Inkrement gebunden ist. Dennoch zeigt die Studie von Ron Lichty zur Product Team Performance, dass nur 45 % der Teams eine DoD haben, die ihr eigenes Team erstellt hat. Der Rest arbeitet entweder ohne eine oder folgt einer Checkliste, die ihnen jemand anderes gegeben hat. Der interessante Punkt: Nur von Teams selbst erstellte Definitions of Done korrelieren mit hoher Leistung. Extern auferlegte zeigen keinerlei Korrelation.

Was die Definition of Done wirklich ist

Die DoD ist ein gemeinsamer Qualitätsstandard, der für jedes Arbeitsergebnis gilt, das dein Team liefert. Sie ist nicht dasselbe wie Akzeptanzkriterien.
Definition of DoneAkzeptanzkriterien
GeltungsbereichUniversal, gilt für alle ArbeitSpezifisch für eine Story
FokusQualitäts- und ProzessstandardsFunktionale Anforderungen
Wer schreibt esDas gesamte Scrum-TeamProduct Owner (mit Team-Input)
Beispiel"Code von mindestens einem Entwickler gereviewed""Benutzer kann nach Datumsbereich filtern"
Beide müssen erfüllt sein, bevor eine Story abgeschlossen ist. Akzeptanzkriterien sagen dir, was du bauen sollst. Die DoD sagt dir, wie gut es gebaut sein muss.

Eine Definition of Done Checkliste auf drei Stufen

Nicht jedes Team braucht dieselbe DoD. Ein Startup, das sein MVP ausliefert, hat andere Qualitätsanforderungen als eine Gesundheitsplattform mit Compliance-Anforderungen. Hier ist ein gestufter Ansatz.

Starter-DoD

Für Teams, die gerade erst mit einer formalen Definition of Done beginnen:

Code von mindestens einem anderen Entwickler per Peer-Review geprüft

Unit-Tests geschrieben und bestanden

Keine neuen Compiler-Warnungen oder -Fehler

Akzeptanzkriterien verifiziert

Code in den Main-Branch gemergt

Baut erfolgreich aus der Versionsverwaltung

Fortgeschrittene DoD

Für Teams mit etablierter CI/CD-Pipeline und ein paar Sprints Erfahrung:

Code von mindestens einem anderen Entwickler per Peer-Review geprüft

Unit-Tests geschrieben und bestanden

Code-Abdeckung sinkt nicht unter den aktuellen Schwellenwert

Integrationstests bestanden

Keine kritischen oder hochgradigen Bugs verbleiben

Akzeptanzkriterien End-to-End verifiziert

In Staging-Umgebung bereitgestellt

Product Owner hat geprüft und freigegeben

Technische Dokumentation aktualisiert

Barrierefreiheitsstandards eingehalten

Experten-DoD

Für erfahrene Teams, die jeden Sprint in Produktion ausliefern:

Code von mindestens einem anderen Entwickler per Peer-Review geprüft

Unit-, Integrations- und Regressionstests bestanden

Code-Abdeckung gehalten oder verbessert

Sicherheits-Schwachstellenscan bestanden

Performance-Benchmarks eingehalten

In Produktion hinter Feature-Flag bereitgestellt

Monitoring und Alerting konfiguriert

Benutzerorientierte Dokumentation aktualisiert

Release Notes geschrieben

Akzeptanzkriterien in Produktion verifiziert

Product-Owner-Freigabe erteilt

Team blickt auf einen großen Monitor, der eine CI/CD-Pipeline mit grünen Häkchen an jeder Stufe zeigt und automatisierte Qualitäts-Gates darstelltTeam blickt auf einen großen Monitor, der eine CI/CD-Pipeline mit grünen Häkchen an jeder Stufe zeigt und automatisierte Qualitäts-Gates darstellt Die richtige Stufe hängt von eurem Kontext ab. Beginnt mit einer Checkliste, die euer Team konsequent einhalten kann, und hebt dann die Messlatte im Laufe der Zeit an. Punkte hinzuzufügen, die euer Team routinemäßig überspringt, trainiert nur alle darin, die DoD komplett zu ignorieren.

Warum die DoD für Schätzungen wichtiger ist, als man denkt

Hier hören die meisten Artikel über die Definition of Done auf. Aber die Verbindung zwischen DoD und Schätzgenauigkeit ist der am meisten unterschätzte Grund, sie richtig zu machen. Der Scrum Guide sagt es klar: Entwickler schätzen sicherer, wenn sie ihre Definition of Done verstehen. Wenn dein Team eine Story beim Planning Poker schätzt, sollte diese Schätzung alles beinhalten, was nötig ist, um die DoD zu erfüllen. Nicht nur das Schreiben des Codes, sondern auch das Review, die Tests, das Deployment -- alles. Teams, die nur den Codierungsaufwand schätzen und dann am Ende des Sprints die DoD-Aktivitäten entdecken, übernehmen sich konsequent. Die Arbeit hat nicht länger gedauert als geschätzt. Die Schätzung hat nur die Hälfte der Arbeit ignoriert. Wenn ihr neue Punkte zu eurer DoD hinzufügt (wie Sicherheitsscans oder Performance-Tests), erwartet einen vorübergehenden Velocity-Rückgang. Das ist gesund. Eure Velocity wird einfach nur ehrlich.

Fünf Anti-Patterns, die eure DoD untergraben

1. Einmal erstellt und vergessen

Das Team hat vor sechs Monaten eine DoD geschrieben und seitdem nicht mehr angeschaut. Tools ändern sich und das Produkt wächst. Überprüft die DoD in euren Retrospektiven, auch wenn ihr sie nicht jedes Mal ändert.

2. Von einer Person erstellt

Ein Tech Lead oder Scrum Master erstellt die DoD allein und präsentiert sie als fertig. Der Rest des Teams fühlt sich nie dafür verantwortlich und behandelt sie als optional. Die Lösung: Baut sie gemeinsam in einem Workshop auf. Jeder, der die Arbeit macht, sollte ein Mitspracherecht haben, was "fertig" bedeutet.

3. Zu vage, um überprüfbar zu sein

"Code ist von guter Qualität" und "Testing erledigt" sind nicht überprüfbar. Jeder Punkt sollte eine klare Bestanden/Nicht-bestanden- Bedingung haben. "Code besteht die statische Analyse ohne kritische Probleme" ist etwas, das man prüfen kann. "Code ist sauber" ist Ansichtssache. Person blickt auf eine riesige Checkliste, bei der einige Punkte klar als erledigt markiert sind und andere mehrdeutig bleiben, was den Unterschied zwischen vagen und spezifischen Kriterien veranschaulichtPerson blickt auf eine riesige Checkliste, bei der einige Punkte klar als erledigt markiert sind und andere mehrdeutig bleiben, was den Unterschied zwischen vagen und spezifischen Kriterien veranschaulicht

4. Die Messlatte unter Druck senken

Wenn Deadlines knapp werden, schwächen Teams manchmal die DoD, um schneller zu liefern. Der Scrum Guide 2020 ist hier eindeutig: Die DoD kann sich weiterentwickeln, um die Qualität zu verbessern, aber sie sollte nicht abgeschwächt werden. Abkürzungen bei der Qualität machen euch nicht schneller. Sie erzeugen die Illusion von Geschwindigkeit, während sie Probleme für zukünftige Sprints anhäufen.

5. DoD mit Akzeptanzkriterien verwechseln

Die DoD ist universell. Akzeptanzkriterien sind story-spezifisch. Sie zu vermischen bedeutet, dass ihr entweder den Qualitätsstandard verliert oder die funktionalen Anforderungen vergesst. Behaltet sie als separate Checklisten, die zusammenwirken.

So erstellt ihr eure erste DoD

Wenn euer Team noch keine Definition of Done hat, hier ist eine praktische Vorgehensweise, um eine zu erstellen.
Beginnt mit dem, was bereits passiert
Fragt euer Team: "Was tun wir bereits, bevor wir etwas als fertig bezeichnen?" Schreibt jede Antwort auf. Die meisten Teams haben bereits informelle Standards, die noch nicht dokumentiert wurden.
Identifiziert die Lücken
Schaut euch aktuelle Bugs oder Produktionsvorfälle an. Was hätte sie früher aufgefangen? Diese Lücken werden zu Kandidaten für neue DoD-Punkte.
Haltet es kurz
Zielt auf 6-12 Punkte ab. Jeder Punkt sollte seinen Platz verdienen, indem er eine echte Problemkategorie verhindert. Wenn ihr nicht auf ein konkretes Problem verweisen könnt, das ein Punkt auffangen würde, streicht ihn.
Macht sie sichtbar
Hängt die DoD dort auf, wo das Team sie während der Sprint-Planung und der täglichen Arbeit sehen kann. Eine Checkliste, die in einem Wiki vergraben ist, ist eine Checkliste, die niemand liest.
Überprüft sie in jeder Retrospektive
Fügt einen festen Tagesordnungspunkt zu euren Retros hinzu. Fragt: "Hat die DoD aufgefangen, was nötig war? Ist etwas durchgerutscht? Sollten wir Punkte hinzufügen oder entfernen?"

Was leistungsstarke Teams anders machen

Ron Lichtys Forschung zeigt ein klares Muster. Leistungsstarke Teams sind Eigentümer ihrer DoD und entwickeln sie bewusst weiter. Sie nutzen sie auch, um Schätzungen ehrlich statt optimistisch zu halten. Diese Teams automatisieren so viel von der Checkliste wie möglich. Code-Coverage-Checks und statische Analyse laufen in CI/CD-Pipelines neben Sicherheitsscans. Die DoD wird vom System durchgesetzt statt aus dem Gedächtnis, was dem Team erlaubt, sich auf die Punkte zu konzentrieren, die tatsächlich menschliches Urteilsvermögen erfordern -- wie ob die Akzeptanzkriterien aus der Perspektive des Benutzers erfüllt sind. Die ausgereiftesten Teams verknüpfen ihre DoD mit Geschäftsergebnissen, nicht nur mit technischen Standards. Martin Hinshelwood gibt ein Beispiel: "Live in Produktion, Telemetrie sammelnd, die Ausgangshypothese unterstützend oder widerlegend." Das ist ein Team, dessen Definition of Done nicht nur "der Code funktioniert" ist, sondern "wir lernen aus dem, was wir ausgeliefert haben."

Erste Schritte

Wählt drei Punkte aus der Starter-Checkliste oben. Schreibt sie auf ein Whiteboard oder in ein gemeinsames Dokument. Nutzt sie für einen Sprint. Fragt in der Retro, was funktioniert hat und was fehlt. Fügt ein oder zwei Punkte hinzu. Wiederholt das. Eine kleine, konsistente DoD, der das Team tatsächlich folgt, schlägt eine umfassende, die alle ignorieren. Baut zuerst die Gewohnheit auf, dann hebt die Messlatte an. Und beim nächsten Mal, wenn jemand fragt, ob eine Story fertig ist, habt ihr eine Antwort, die kein 10-Minuten-Gespräch erfordert. Wenn euer Team Planning Poker zur Schätzung verwendet, haltet die DoD während dieser Sitzungen sichtbar. Es ist der schnellste Weg sicherzustellen, dass Schätzungen den vollen Umfang dessen widerspiegeln, was "fertig" wirklich bedeutet.

Überprüft sie in jeder Sprint-Retrospektive. In den meisten Sprints werdet ihr nichts ändern, aber die Gewohnheit hält sie relevant. Aktualisiert sie, wenn ihr wiederkehrende Qualitätslücken findet oder wenn neue Tools bestehende Punkte automatisierbar machen.

Der Scrum Guide besagt, dass Teams, wenn eine Organisation eine Standard-DoD hat, diese als Minimum einhalten müssen. Teams können strengere Standards darüber hinaus hinzufügen. In der Praxis sollte jedes Team die Punkte über der organisatorischen Basislinie selbst verantworten.

Die Definition of Ready deckt ab, ob ein Backlog-Item genügend Informationen hat, um mit der Arbeit zu beginnen (klare Anforderungen, Abhängigkeiten identifiziert). Die Definition of Done deckt ab, ob die fertige Arbeit den Qualitätsstandards entspricht. Ready ist das Eingangstor, Done ist das Ausgangstor.

Nein. Wenn sie nicht die vollständige DoD erfüllt, ist sie nicht fertig. Sie geht zurück ins Product Backlog. Teilweise erledigte Arbeit sollte niemals im Sprint Review präsentiert oder zur Velocity gezählt werden.
Zuletzt aktualisiert am 10/02/2026