Der Sprint endet, das Ticket steht auf „Done” und trotzdem hat noch niemand das Feature getestet, dokumentiert oder reviewt. Genau das verhindert eine klare Definition of Done. Sie legt fest, welche Kriterien erfüllt sein müssen, bevor ein Product Backlog Item als Increment zählt. Bei der Entwicklung Ihrer Individualsoftware setzen wir deshalb von Anfang an auf eine saubere DoD.
Dieser Beitrag erklärt, was eine gute DoD ausmacht und wie Sie sie gemeinsam mit Ihrem Team aufsetzen. Außerdem zeigt er, welche Fehler Sie dabei vermeiden sollten.
Was die Definition of Done in Scrum ist
Die Definition of Done, kurz DoD, beschreibt die Qualitätsanforderungen, die ein Increment erfüllen muss. Erst wenn ein Product Backlog Item diese Anforderungen erfüllt, gilt es als fertig.
Wie der Scrum Guide die DoD definiert
Der offizielle Scrum Guide beschreibt die DoD als formale Beschreibung des Zustands, den ein Increment erreichen muss.[^1] Erfüllt ein Element diese Beschreibung nicht, entsteht kein Increment, sondern es wandert zurück ins Product Backlog.
Seit der Scrum Guide-Version 2020 zählt die DoD zu den drei Commitments von Scrum, neben Sprint-Ziel und Product-Ziel.[^1] Damit ist sie kein optionales Extra, sondern fester Bestandteil des Frameworks. Mehr zu den Grundlagen erklärt der Eintrag zu Scrum im Lexikon.
Warum eine gute DoD Qualität in Scrum-Teams sichert
Ohne DoD entscheidet am Ende jede Person im Team selbst, was „fertig" bedeutet. Diese Uneinigkeit fällt selten sofort auf, sondern erst, wenn Kunden oder Stakeholder ein Ergebnis anders bewerten als erwartet.
Was passiert, wenn Teams ohne DoD arbeiten
Ohne klare Kriterien häufen sich unfertige Arbeiten an, die auf den ersten Blick fertig wirken. Ohne diese Klarheit können Stakeholder kein verlässliches Feedback geben, wie Scrum.org betont.[^2]
Die Folge sind späte Überraschungen. Code bleibt ungetestet, Dokumentation fehlt oder Funktionen sind zwar technisch fertig, aber fachlich nicht abgenommen. Genau das untergräbt das Vertrauen in Sprint Reviews, weil gezeigte Ergebnisse nicht wirklich nutzbar sind.
Wie Sie eine Definition of Done aufsetzen
Eine gute DoD entsteht nicht am Schreibtisch einer einzelnen Person, sondern gemeinsam im Team.
Wer die DoD gemeinsam erarbeiten sollte
Product Owner, Scrum Master und Developers bringen jeweils eine eigene Perspektive ein. Der Product Owner kennt die fachlichen Erwartungen, die Developers kennen die technische Machbarkeit.
Der Scrum Guide macht deutlich, dass die Developers verpflichtet sind, sich an die Definition of Done zu halten.[^1] Deshalb sollten sie die Kriterien auch aktiv mitgestalten, statt sie nur vorgegeben zu bekommen.
Welche Done-Kriterien typischerweise dazugehören
Eine DoD deckt meist mehrere Bereiche ab. Dazu zählen bestandene Tests, ein durchgeführtes Code Review, aktualisierte Dokumentation und eine erfolgreiche Bereitstellung in der Testumgebung.
Wie Code Reviews konkret zur Qualität beitragen, erklärt der Beitrag zu Code Reviews in der Softwareentwicklung. Nicht jedes Kriterium passt zu jedem Projekt. Entscheidend ist, dass die gewählten Kriterien tatsächlich überprüfbar sind.
Wie Sie die DoD im Team verankern
Eine DoD nützt nichts, wenn sie nur in einem Dokument steht, das niemand liest. Hängen Sie die Kriterien sichtbar neben dem Scrum Board oder Kanban Board auf, damit sie im Alltag präsent bleiben. Mehr zum Zusammenspiel beider Boards zeigt der Beitrag zu Scrum vs. Kanban.
Prüfen Sie die DoD regelmäßig in der Retrospektive. Passen Sie sie an, wenn sich die Anforderungen an Qualität oder Projektumfang ändern.
Welche typischen Fehler beim Aufsetzen passieren
Ein häufiger Fehler ist eine DoD, die zu allgemein bleibt, etwa nur „Code funktioniert". Solche Kriterien lassen sich nicht überprüfen und bieten daher keine echte Orientierung.
Ein zweiter Fehler ist das Gegenteil. Eine DoD mit zu vielen Kriterien wird im Alltag oft nicht mehr vollständig eingehalten. Realistische Kriterien wirken langfristig besser als eine perfekte Liste, die ignoriert wird.
Ein dritter Fehler ist, die DoD einmalig festzulegen und nie wieder anzupassen. Teams entwickeln sich weiter. Ihre Qualitätsansprüche sollten mitwachsen. Wie sich Anforderungen und Vorgehen insgesamt weiterentwickelt haben, ordnet der Beitrag zur agilen Softwareentwicklung ein.
Fazit
Eine Definition of Done macht sichtbar, was „fertig" in Ihrem Team tatsächlich bedeutet. Sie schützt vor unfertiger Arbeit, die auf den ersten Blick abgeschlossen wirkt und schafft Vertrauen in jedes Sprint Review.
Wichtig ist, dass die DoD gemeinsam im Team entsteht, aus überprüfbaren Kriterien besteht und regelmäßig überprüft wird. So bleibt sie ein Werkzeug, das tatsächlich genutzt wird, statt ein Dokument, das in der Schublade verschwindet.
Sie möchten Ihre Scrum-Prozesse auf ein solides Fundament stellen? Vereinbaren Sie ein kostenloses Erstgespräch. Gemeinsam ordnen wir ein, wo der größte Hebel für Ihr Team liegt.
Fußnoten und Quellen
[^1]: Ken Schwaber und Jeff Sutherland, „The Scrum Guide", offizielle Ausgabe November 2020. https://scrumguides.org/scrum-guide.html [^2]: Scrum.org, „What is the Definition of Done?". https://www.scrum.org/resources/what-definition-done
