HelloAgile® | HelloNew GmbH & Co. KG
Mosbacher Straße 9, 65187 Wiesbaden
Die Definition of Done (DoD) ist der Qualitätsstandard, auf den sich das Scrum Team geeinigt hat. Sie besteht aus Eigenschaften, die jede Lösung eines Sprint Backlog Items aufweisen muss, um als "fertig" zu gelten und ins Review aufgenommen werden zu können.
21.5.2026
Jedes Scrum-Team steht früher oder später vor derselben Frage: Ab wann gilt eine Aufgabe als erledigt? Die Definition of Done gibt darauf eine verbindliche Antwort. Sie ist eine gemeinsam vereinbarte Liste von Kriterien, die ein Product Increment erfüllen muss, bevor das Team es als fertig betrachtet. Ohne diese Vereinbarung entsteht Interpretationsspielraum, und Interpretationsspielraum kostet Zeit,Qualität und Vertrauen.
Qualitätsstandards, technische Anforderungen und prozessuale Schritte bilden die Basis jeder Definition of Done. Das unterscheidet sie vonAkzeptanzkriterien, die für einzelne User Stories spezifisch sind. Während Akzeptanzkriterien beschreiben, was ein Feature leisten soll, legt die Definition of Done fest, wie fertig "fertig" bedeutet. Nur vollständig erfüllte Kriterien berechtigen dazu, das Product Increment im Sprint Review vorzustellen.
Wenn man die Definition of Done als Qualitätsanforderungen an alle Aufgaben, die im Sprint bearbeitet werden versteht, dann hat sie zwei Funktionen: Sie stellt sowohl sicher, dass genügend als auch dass nicht zu viel Arbeit in eine Anforderung fließt. Zeigt sich im Review, dass die Qualität der Entwicklung nicht gut genug ist, wird die Definition of Done in der Retrospektive angepasst.
Die Definition of Done gilt dabei für alle Items gleichermaßen. Hat man für einzelne Aufgaben besondere zusätzliche Anforderungen, nennt man diese "Akzeptanzkriterien". Sie fungieren wie die Definition of Done, sind jedoch nicht allgemein gültig.
Acht Schritte führen zu Kriterien, die das Team trägt und im Alltag tatsächlich anwendet. Etliche Teams scheitern nicht an fehlendem Willen,sondern daran, dass sie den Prozess zu schnell angehen und wichtige Grundlagen überspringen. Gute Kriterien brauchen Zeit, Diskussion und den Input aller Beteiligten. Schlechte entstehen, wenn eine Person allein entscheidet und den Rest vor vollendete Tatsachen stellt. Strukturiertes Vorgehen spart späterlange Debatten im Sprint.
Die Definition of Done gehört dem gesamten Team. Scrum Master, Product Owner und Development Team erarbeiten sie gemeinsam, weil sichergestellt ist, dass alle Beteiligten die Vereinbarung verstehen und mittragen. Außenstehende betrachten die Vereinbarung nicht als ihre eigene.
Jedes Team arbeitet bereits mit stillschweigenden Qualitätserwartungen. Sinnvoll ist es, diese zuerst sichtbar zu machen, bevor neue Kriterien formuliert werden. Fragen wie "Was haben wir bisher immer gemacht, ohne es aufzuschreiben?" bringen genau jene Annahmen ans Licht, die später für Konflikte sorgen, wenn sie unausgesprochen bleiben.
Konkrete Aussagen schlagen vage Beschreibungen in jedem Fall. Statt "ausreichend getestet" lieber "Alle Unit Testslaufen fehlerfrei durch." Bei Dokumentation gilt dasselbe: „Jede neue Funktion hat eine Beschreibung im Confluence." Kurze, aktive Sätze, die sich direkt auf den Arbeitsalltag beziehen, funktionieren am besten.
Prüfbarkeit bedeutet, dass sich jedes Kriterium mit Ja oder Nein beantworten lassen muss. Formulierungen, die Interpretationsspielraum lassen, unterhöhlen die gesamte Vereinbarung. Das Team prüft jeden Punkt mit der Frage: Können zwei Personen unabhängig voneinander zum selben Ergebnis kommen? Lautet die Antwort nein, braucht das Kriterium eine Überarbeitung.
Manche Kriterien gelten für jede einzelne User Story, anderebetreffen das gesamte Inkrement. Diese Unterscheidung verhindert, dass Story-spezifische Anforderungen fälschlicherweise auf Inkrement-Ebene angewendet werden und umgekehrt. Zwei separate Listen schaffen hier Klarheit.
Abstimmung bedeutet nicht, dass alle begeistert sind. Ziel ist, dass alle Beteiligten die Kriterien akzeptieren und bereit sind, nach ihnen zu arbeiten. Offene Einwände gehören in diese Phase, nicht in den laufenden Sprint. Ungelöste Konflikte über Qualitätsstandards kosten später mehr Zeit als die Diskussion jetzt.
Mündliche Vereinbarungen verblassen schneller als erwartet. Schriftlich festgehaltene Kriterien stehen jedem Teammitglied jederzeit zur Verfügung und bilden die Grundlage für neue Kolleginnen und Kollegen, die stoßen. Praktisch bewährt hat sich ein zentraler Ablageort, den alle kennen und auf den alle Zugriff haben. Tools wie Confluence oder Jira eignen sich gut als zentrale Ablage. Entscheidend ist nicht das Format, sondern die Zugänglichkeit. Kriterien, die niemand findet, wirken genauso wenig wie Kriterien, die niemand kennt. Neue Teammitglieder sollten die Definition of Done am ersten Tag lesen können, ohne erst fragen zu müssen.
Standards entwickeln sich weiter. Überholte Punkte bremsen das estiTeam, statt es zu unterstützen. Beim Product Backlog Refinement oder spätestens in der Retrospektive prüft das Team, ob die bestehenden Punkte noch greifen, und passt sie bei Bedarf an.
Theorie hilft nur so weit, bis man sieht, wie eine Definition of Done in der Praxis aussieht. Teams, die Scrum-Guides gelesen haben, wissen oft, was Fertigstellungskriterien sein sollen, aber nicht, wie sie konkret formuliert werden. Nachfolgend ein Beispiel eines fünfköpfigen Software-Entwicklungsteams, das eine Web-Applikation für einenmittelständischen Händler baut und seit mehreren Sprints mit einer stabilen Definition of Done arbeitet. Solche Kriterien entstehen nicht in einer Stunde, sondern entwickeln sich über mehrere Retrospektiven hinweg. Nutzen Sie es als Ausgangspunkt, nicht als fertige Vorlage zum Kopieren.
- Mindestens eine weitere Person hat den Code reviewed und kommentiert.
- Alle Unit Tests laufen fehlerfrei durch, die Testabdeckungliegt bei mindestens 80%.
- Offene Blocker-Issues im Issue-Tracker gibt es keine.
- Sämtliche Akzeptanzkriterien der User Story hat das Team erfüllt und der Product Owner hat sie freigegeben.
- Das Feature läuft stabil in der Staging-Umgebung, nicht nur lokal.
- Randfälle und Fehlerzustände hat das Team getestet und behandelt.
- Neue Funktionen haben einen Eintrag im internen Wiki.
- API-Änderungen hält das Team im Changelog fest.
- Den fertigen Stand demonstriert das Team im Review Meeting.
- Folgethemen landen direkt im Backlog.
Zahlreiche Teams erstellen eine Definition of Done und legen sie anschließend in einer Schublade ab. Nachlassende Konsequenz bei ist der häufigste Grund, warum Qualitätsstandards im Sprint erodieren. Brauchbare Kriterien nützen nichts, wenn das Team sie im Alltag ignoriert oder bei Zeitdruck stillschweigend außer Kraft setzt. Negative Gewohnheiten entstehen schnell und sind schwer wieder loszuwerden.
Unklare Formulierungen sind der klassische Einstiegsfehler. Begriffe wie "ausreichend" oder "angemessen" laden zur Interpretation ein und führen dazu, dass zwei Personen denselben Punkt unterschiedlich bewerten. Präzise Kriterien, die sich mit Ja oder Nein beantworten lassen, lösen dieses Problem an der Wurzel. Ungenaue Kriterien wirken sich direkt auf die Story Points aus, weil niemand den Aufwand realistisch schätzen kann, wenn unklar ist, was fertig bedeutet.
Zeitdruck verleitet Teams dazu, Kriterien stillschweigend zuübergehen. Sobald das Team das einmal durchgehen lässt, sinkt die Hemmschwelle beim nächsten Mal. Konsequente Einhaltung schützt die Qualität des Inkrements und bestimmt direkt, was im Sprint Review gezeigt werden darf. Aufgabe des Scrum Masters ist es, die Einhaltung einzufordern, auch wenn der Sprint eng wird.
Starre Kriterien, die sich nie verändern, verlieren mit der Zeit ihren Bezug zur Realität. Reife Teams überprüfen ihre Definition of Done regelmäßig und passen sie an neue Gegebenheiten an. Passend dafür ist der Rahmen der Retrospektive, weil das Team dort ohnehin über Arbeitsweise und Qualität spricht. Verpasste Anpassungen rächen sich spätestens dann, wenn neue Teammitglieder nach Kriterien arbeiten, die längst überholt sind.
Die Definition of Ready und die Definition of Done arbeiten im selben Prozess, aber an unterschiedlichen Stellen. Beide Vereinbarungen schaffen Klarheit, jedoch über verschiedene Fragen: Letztere klärt, wann eine Aufgabe bereit ist, angefangen zu werden. Die andere klärt, wann sie fertig ist.
Konkret bedeutet das: Die Definition of Ready legt fest, welche Voraussetzungen ein Backlog-Item erfüllen muss, bevor das Team es in einen Sprint zieht. Typische Punkte sind "Akzeptanzkriterien sind formuliert" oder "Aufwand ist geschätzt". Danach greift die Definition of Done und beschreibt, was das Team geliefert haben muss, bevor es ein Item als abgeschlossen betrachtet.
Gegenseitig ergänzen sie sich. Schwache Voraussetzungen auf der Ready-Seite führen zu schlecht definierten Aufgaben im Sprint. Mangelnde Klarheit auf der Done-Seite führt zu halbfertigen Ergebnissen im Review. Stringente Pflege beider Vereinbarungen schafft einen Rahmen, in dem Qualität keine Frage der Interpretation bleibt.
Beide Konzepte beschreiben Qualitätserwartungen, aber auf unterschiedlichen Ebenen. Akzeptanzkriterien gelten für eine einzelne User Story und beschreiben, was dieses spezifische Feature leisten muss. Die Definition of Done gilt für alle Items gleichermaßen und legt fest, welche allgemeinen Qualitätsstandards jedes Inkrement erfüllen muss. Kurz gesagt: Akzeptanzkriterien sind itemspezifisch, die Definition of Done ist teamweit.
Nein. Jedes Team legt seine eigene Definition of Done fest, abgestimmt auf die eigene Arbeitsweise, den Technologie-Stack und die Qualitätsanforderungen des Produkts. Organisationen mit mehreren Teams, die am selben Produkt arbeiten, sollten sich auf eine gemeinsame Basis einigen und diese teamübergreifend abstimmen. Individuelle Ergänzungen pro Team sind dabei möglich.
Länge ist kein Qualitätsmerkmal. Kurze Listen mit präzisen Kriterien funktionieren besser als lange Listen mit vagen Formulierungen. Fünf bis fünfzehn Punkte haben sich in der Praxis als handhabbar erwiesen. Alles darüber hinaus erhöht die Komplexität, ohne die Qualität zu steigern.
Nicht erfüllte Kriterien bedeuten, das Item gilt nicht als fertig. Zurück in den Sprint kommt es nicht, weil der Sprint endet. Stattdessenlandet es unfertig im nächsten Sprint Planning, wo das Team entscheidet, ob und wann es die Arbeit abschließt. Dieser Mechanismus schützt das Team davor, halbfertige Arbeit als Fortschritt zu verbuchen.
Kurzfristige Änderungen während eines laufenden Sprintsuntergraben die Planungsgrundlage und schaffen Unsicherheit im Team. Mitten im Sprint angepasste Kriterien entziehen der ursprünglichen Schätzung die Grundlage. Überlegte Anpassungen gehören in die Retrospektive, wo das Team in Ruhe darüber sprechen kann, ohne den laufenden Sprint zu gefährden.
21.5.2026
