Beiträge

Die Definition of Done Checkliste, die dein Team wirklich braucht

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 Done	Akzeptanzkriterien
Geltungsbereich	Universal, gilt für alle Arbeit	Spezifisch für eine Story
Fokus	Qualitäts- und Prozessstandards	Funktionale Anforderungen
Wer schreibt es	Das gesamte Scrum-Team	Product 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:

Fortgeschrittene DoD

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

Experten-DoD

Für erfahrene Teams, die jeden Sprint in Produktion ausliefern: 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.

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. Für einen schnellen Einstieg kann ein Definition-of-Done-Generator eine erste Checkliste basierend auf eurem Teamkontext entwerfen.

1. 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.

2. 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.

3. 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.

4. 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.

5. Ü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.