Definition of Done
Gemeinsame Qualitätsverpflichtung des Teams
Zweck
Definiert verbindlich, wann Arbeit wirklich fertig ist
Die Definition of Done vereinheitlicht das Verständnis des Teams von "fertig" und verhindert, dass Aufgaben durchs Raster fallen. Sie schafft Konsistenz und Fokus bei der Arbeitserledigung. Die DoD sollte vom gesamten Team gemeinsam erstellt und regelmäßig überprüft werden.
💡 Key Insight
Die Definition of Done macht unser gemeinsames Qualitätsverständnis explizit sichtbar.
Video: Definition of Done
Bestandteile
- Qualitätskriterien (Code, Tests, Docs)
- Technische Standards und Best Practices
- Dokumentationsanforderungen
- Testing-Anforderungen (Unit, Integration, E2E)
Was gehört in eine Definition of Done?
Eine Definition of Done kann verschiedene Qualitätskriterien umfassen, je nach Kontext des Teams und Produkts:
Code-Qualität
Code-Reviews durchgeführt, Coding Standards eingehalten, keine bekannten Bugs, technische Schulden dokumentiert. Der Code sollte nicht nur funktionieren, sondern auch wartbar und verständlich für andere Teammitglieder sein.
Test-Abdeckung (Testing-Pyramide)
Unit Tests für Geschäftslogik geschrieben und bestanden, Integration Tests für Schnittstellen vorhanden, End-to-End Tests für kritische User Journeys durchgeführt. Die Testing-Pyramide hilft: Viele schnelle Unit Tests an der Basis, weniger Integration Tests in der Mitte, noch weniger langsame E2E Tests an der Spitze.
Dokumentation
Inline-Code-Kommentare für komplexe Logik, README aktualisiert, API-Dokumentation gepflegt, User-Dokumentation oder Changelog erweitert. Dokumentation sollte zukünftigen Entwicklern und Nutzern helfen, die Änderungen zu verstehen.
Technische Standards
Performance-Anforderungen erfüllt, Accessibility-Standards eingehalten (WCAG), Security Best Practices befolgt, responsive Design getestet. Diese Standards sichern die Qualität über funktionale Anforderungen hinaus.
Integration & Deployment
Code in Hauptbranch integriert, CI/CD-Pipeline durchlaufen, auf Staging-Umgebung deployt und getestet, keine Merge-Konflikte mehr offen. Dies stellt sicher, dass die Arbeit wirklich "fertig" ist und nicht nur lokal funktioniert.
Best Practices
- ✓DoD regelmäßig reviewen und aktualisieren
- ✓DoD kollaborativ mit gesamtem Team erstellen
- ✓Methoden wie Brainwriting nutzen für umfassende Kriterien
- ✓DoD explizit machen und im Team teilen
Häufige Fehler
- ✗DoD als statische Checkliste behandeln
- ✗DoD NICHT aktiv pflegen und weiterentwickeln
- ✗DoD NICHT explizit und geteilt im Team machen
Typische Elemente einer Definition of Done
Häufig gestellte Fragen zu Definition of Done
Was ist die eigentliche Intention einer Definition of Done?
Die Intention ist, ein klares, gemeinsames Verständnis im Team zu schaffen, was 'fertig' konkret bedeutet. Sie dient als explizite Vereinbarung, um Fokus und Konsistenz in den kurzen Scrum-Zyklen zu gewährleisten. Dadurch werden vergessene Aspekte wie Tests, Dokumentation oder Integration vermieden, die in kurzen Sprints zu großen Blockaden werden können. Sie ist ein lebendiges Artefakt, das hilft, ruhiger und proaktiver das Richtige zu liefern.
Wie kann man verhindern, dass die Definition of Done zu einer starren Checkliste wird?
Indem man sie als lebendes Artefakt begreift und regelmäßig pflegt. Ein praktischer Weg ist die Integration in die Retrospektive, z.B. mit der 'Story Oscar und Story Himbeere'-Übung, wo beste und schlechteste Arbeitsweisen analysiert werden. Daraus werden Anpassungen abgeleitet. Zudem hilft eine visuelle Ampelbewertung (grün/gelb/rot) mit dem gesamten Team, um den aktuellen Erfüllungsgrad und Relevanz jedes Punkts zu diskutieren und sie so aktiv zu halten.
In welchen Scrum-Events sollte die Definition of Done präsent und genutzt werden?
Sie sollte aktiv in mehreren Events genutzt werden: Im Backlog Refinement, um Anforderungen ganzheitlich zu betrachten. Im <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Planning</a>, um bei der Auswahl und Detaillierung von Aufgaben sicherzustellen, dass alle 'Done'-Kriterien bedacht werden. Besonders wirkungsvoll ist sie, wenn ein Entwickler meint, fertig zu sein – der Abgleich mit der DoD zeigt oft vergessene Punkte. Auch im Daily kann sie helfen, den Fortschritt zu hinterfragen.
Was ist eine praktische Methode, um eine erste Definition of Done zu erstellen?
Eine strukturierte Methode ist ein Brainwriting mit dem gesamten Team. Jeder notiert für sich auf Post-its: 1) Was machen wir neben der Funktionalität IMMER? 2) Was machen wir MANCHMAL? 3) Was sollten wir tun, tun es aber NICHT? Die Punkte werden gesammelt, in Themenclustern geordnet und priorisiert. Anschließend arbeiten Kleingruppen konkrete Formulierungen und Begründungen für die wichtigsten Themen aus. So entsteht ein gemeinsamer, motivierter erster Wurf.
Warum sollte eine Definition of Done nicht zu umfangreich sein?
Ein zu umfangreicher Katalog ist wie ein überambitionierter Sportplan – er wird schnell fallengelassen. Besser ist es, sich auf wenige, aber wesentliche und konsistent einhaltbare Punkte zu konzentrieren. Im Team sollte explizit besprochen werden, welcher Umfang wichtig, aber noch handhabbar ist. Konsistenz in der Anwendung führt zu besseren Ergebnissen als eine perfekte, aber ungenutzte Liste. Unwichtige Punkte sollten entfernt werden, um den Fokus zu bewahren.
Wie kann ein Scrum Master fördern, dass die Definition of Done aktiv gelebt wird, ohne zum inhaltlichen Treiber zu werden?
Indem er Techniken nutzt, die das Team zur Selbstreflexion anleiten. Statt selbst zu mahnen, kann er z.B. die visuelle Ampelbewertung moderieren und das Team fragen: 'Wie seht ihr den Status dieses Punkts?'. Oder er integriert die DoD-Pflege in Retrospektiven. Das Ziel ist, bewusste Entscheidungen aus dem Team heraus entstehen zu lassen. Der Scrum Master schafft den Raum und die Struktur für diese Gespräche, überlässt die inhaltliche Steuerung aber dem Team.
Nächste Schritte
Möchtest du mehr über Scrum Artefakte lernen? Besuche unsere anderen Seiten oder höre dir die passenden Podcast-Folgen an.
Definition of Done - Podcast-Folgen
#59: Product Increment – Inkrementelle Entwicklung in Scrum
Product Increment verstehen: Warum echte inkrementelle Entwicklung entscheidend ist, wie Teams jedes Sprint lieferbaren Wert schaffen, Feedback erhalten. Inkrement richtig gemacht.
#60: Product Discovery & Scrum
Teams verlieren den Fokus auf Lernen und bauen nur noch Features ab. Wie Product Discovery hilft, bessere Product Increments zu liefern, ohne Scrum zu ersetzen.