Definition of Done: Beispiel, Checkliste und Workshop in Scrum

Neulich habe ich gemeinsam mit einer Kollegin einen Workshop vorbereitet. Inhaltlich hatten wir uns schnell geeinigt, worum es gehen sollte, es fehlte nur noch die passende PowerPoint-Präsentation. Um möglichst effizient an der Präsentation arbeiten zu können, teilten wir sie thematisch auf. Als wir uns dann zusammensetzten, um den fertigen Entwurf durchzusprechen, zeigte sich ein großes Problem: Wir hatten ganz unterschiedliche Vorstellungen davon, was überhaupt einen “fertigen Entwurf” kennzeichnet. 

Auch bei agilen Scrum-Teams kann sich dieses Problem auftun. Nach zwei Wochen gelangt das Team ans Ende des Sprints, aber es herrscht Uneinigkeit darüber, ob das Produktinkrement bereits fertig und aus “in Progress” nach “Done” verschoben werden kann. Diese Uneinigkeit führt zu Diskussionen, welche wiederum das Klima im Team negativ beeinflussen. Um diesen Diskussionen vorzubeugen und die effektive Zusammenarbeit im Team zu schützen, gibt es in der Scrum-Welt ein Artefakt mit dem Namen “Definition of Done” (DoD). 

Was ist die Definition of Done in Scrum?

Die Definition of Done ist die gemeinsame Qualitätsvereinbarung eines Scrum-Teams. Sie beschreibt, welche Bedingungen erfüllt sein müssen, damit ein Inkrement als fertig und nutzbar gilt. Sie ist keine persönliche Aufgabenliste und keine zusätzliche Abnahme durch eine einzelne Rolle, sondern ein transparenter Standard für das gesamte Team.

Wörtlich bedeutet Definition of Done “Definition von Fertig”. Es geht also um eine Einigung des Teams darüber, was getan sein muss, damit ein Feature als fertig angesehen werden kann. Praktisch lässt sich die Definition of Done als eine Art Checkliste darstellen, anhand derer während des Sprints und vor allem am Ende geschaut wird, ob bestimmte Fertigstellungskriterien eingehalten wurden. Diese Kriterien können für Softwareentwicklungsteam beispielsweise folgende sein: 

Definition of Done Beispiel: Checkliste für Scrum-Teams

Eine praxistaugliche Definition of Done kann für ein Softwareprodukt zum Beispiel folgende Kriterien enthalten:

• Die Akzeptanzkriterien und fachlichen Anforderungen sind erfüllt.
• Es wurde eine Dokumentation erstellt.
• Der Code ist vollständig implementiert und kommentiert.
• Es wurde ein Code Review durchgeführt.
• Automatisierte Tests laufen erfolgreich; relevante Fehler und Sicherheitsrisiken sind bearbeitet.
• Die Änderung ist integriert und kann in einer produktionsnahen Umgebung überprüft werden.
• Monitoring, Logging und gegebenenfalls Release Notes sind berücksichtigt.
• Das Inkrement ist nutzbar und erfüllt den Qualitätsstandard des Produkts.
• …

Diese Liste ist ein Beispiel, keine universelle Vorlage. Eine gute DoD schützt Qualität, bleibt für das Team in jedem Sprint anwendbar und wird angepasst, wenn sich Produkt, Risiken oder technische Rahmenbedingungen verändern.

Definition of Done ist nicht dasselbe wie Produktwirkung

Eine Definition of Done beantwortet eine wichtige Frage: Erfüllt das Inkrement den vereinbarten Qualitätsstandard und ist es nutzbar? Sie beantwortet aber nicht automatisch, ob die Änderung im Markt oder beim Kunden die gewünschte Wirkung erzielt.

Für die Praxis hilft deshalb eine Unterscheidung zwischen drei Ebenen:

• Done: Das Inkrement erfüllt die Definition of Done und kann genutzt werden.
• Done-Done: Die Änderung ist integriert, ausgeliefert und im Betrieb beobachtbar.
• Produktwirkung: Reales Kundenfeedback zeigt, ob die Änderung ein relevantes Problem löst und den Produktwert erhöht.

John Cutler beschreibt Software deshalb als kontinuierlich weiterentwickeltes Servicesystem: Features sind keine endgültigen Gebäude, sondern vorübergehende Mittel, um Kundennutzen zu erzeugen. Lies seine Perspektive in The Work Is Never Done.

Gil Zilberfeld unterscheidet außerdem zwischen verschiedenen Bedeutungen von „Done“ – etwa wenn Entwicklung, Tests, Auslieferung oder Kundenfeedback jeweils einen anderen Fertigstellungsgrad markieren. Seine Einordnung findest du in The Definition of Done, Done-Done and Really Done.

Wichtig: „Produktwirkung“ sollte nicht einfach als zusätzliches DoD-Kriterium formuliert werden. Ein Scrum-Team muss ein nutzbares Inkrement liefern; ob es die gewünschte Wirkung erzielt, wird anschließend durch Sprint Review, Nutzung und weitere Lernschleifen sichtbar. Genau diese Trennung schützt die Definition of Done davor, zu einer unerreichbaren Sammelliste zu werden.

Wie die Definition of Done mit weiteren wirksamen Scrum-Praktiken zusammenspielt, zeigen wir in unserem Beitrag Scrum Best Practices 2026.

Warum ist eine Definition of Done wichtig?

Dass das Setzen von Zielen für die Leistung von enormer Bedeutung ist, ist keine neue Erkenntnis. Goal Setting, also Zielsetzung, ist ein viel erforschtes Thema in der Psychologie (vgl. Locke & Latham, 2006). Dabei hat sich gezeigt, dass die Leistung am höchsten ist, wenn Ziele möglichst spezifisch formuliert und herausfordernd sind, ohne dabei unerreichbar zu erscheinen. Bei der Definition of Done handelt es sich jedoch nicht um eine Methode der Zielsetzung (falls ihr jedoch Unterstützung bei der Zielsetzung brauchen könnt, helfen wir gerne); es geht vielmehr um Kriterien, die zur Zielerreichung erfüllt sein müssen. 

Wichtig sind diese Kriterien, um ein gemeinsames Verständnis im Team zu schaffen. Ein Verständnis davon, was jedes Teammitglied leisten muss, um das gemeinsame Ziel zu erreichen. Es geht also um individuelle Leistungen, die sich letztlich zu einer Teamleistung zusammenfügen.

Betrachtet man die Thematik der DoD aus Sicht des Product Owners, zeigen sich ganz andere Problematiken auf. Ist nicht klar definiert, wann ein Produktinkrement als fertig gilt, kann es zu Unstimmigkeiten mit dem Kunden kommen, wenn diesem das Produkt präsentiert wird. Tritt dieser Fall ein und ein nicht fertiges Produkt wird vorgestellt, wird die Möglichkeit des Feedbacks durch den Kunden blockiert. 

Kontinuierliche Verbesserung

Da eine Definition of Done kein statisches Konzept ist, also ständig weiterentwickelt oder verändert werden kann und sollte, bietet sie dem Team zudem die Möglichkeit zu lernen. Wenn das Team am Ende eines Sprints merkt, dass es den Kriterien der Definition of Done nicht gerecht werden konnte, können die Teammitglieder entweder die Definition of Done anpassen, um den tatsächlichen Leistungen entgegenzukommen, oder das Team zieht Schlüsse für den nächsten Sprint und verändert die eigene Arbeitsweise.

Jetzt Echometer kostenlos testen & neue Inspirationen für deine Retrospektiven bekommen!

Echometer kostenlos testen

Diese Reflexionen bezüglich der Definition of Done sollte das Team im Rahmen der Retrospektive durchführen. Mögliche Echometer Items, die zur Vorbereitung abgefragt werden können, lauten 

Wir haben klare Definitions of Done für unsere Anforderungen.

Ich weiß für gewöhnlich, wo wir bei der Erreichung unserer gemeinsamen Ziele stehen.

Meine Ziele sind mit den Zielen meiner Kolleg*innen abgestimmt.

Im Team sind alle Skills abgedeckt, die wir brauchen, um unser Ziel zu erreichen.

Sie hinterfragen nicht nur, ob überhaupt eine Definition of Done im Team vorhanden ist, sondern auch, wie es um die Transparenz, Autonomie und Rollenklarheit im Team bestellt ist.

Den vollständigen Itempool findet ihr in unserem Retro-Tool.

Wie kann unser Team das Done definieren? Ein Beispiel für einen Workshop

Wir haben dir gezeigt, was eine Definition of Done ist und warum diese wichtig sind für die effektive Zusammenarbeit in Scrum-Teams. Wenn dein Team jedoch noch keine DoD erstellt hast, fragst du dich bestimmt, wie das funktioniert. 

Prinzipiell ist es wichtig, dass sich das Team Zeit lässt bei der Erstellung. Am Ende sollte ein Dokument entstehen, mit dem sich jedes Teammitglied identifizieren kann und welches nicht nur als notwendiges Übel gesehen wird. Deswegen empfehlen wir ein workshopartiges Format mit dem Scrum Master als Moderator. Jedes Teammitglied sollte sich Gedanken machen, welche Kriterien für die Fertigstellung des Produkts wichtig sind und diese Gedanken kann das Team dann zusammenfassen. Analog dazu haben wir ein Workshop-Format für Zielsetzung entwickelt. Schaut doch mal rein, um Ideen für euren Definition-of-Done-Workshop zu bekommen! 

Die fertige DoD kann in Retrospektiven beispielsweise in Form der Definition-of-Done-Ampel genutzt werden:  

1. Schreibt eure Kriterien für die Definition of Done untereinander auf.
2. Malt daneben jeweils ein rotes, ein gelbes und ein grünes Feld.
3. Für jeden Punkt der Definition of Done markiert jedes Teammitglied, ob er im letzten Sprint gut umgesetzt wurde, mittel-gut oder schlecht. 
4. Diskutiert die drei mit den häufigsten Nennungen im roten Bereich.
5. Passt ggf. eure Definition of Done an.

Fazit - Fertig?

Noch ein paar Worte zum Schluss: Endgültig “fertig” gibt es im agilen Umfeld nicht. Done bedeutet lediglich, dass etwas vorläufig fertig ist, aber weitere Anpassungen und Verbesserungen zu jeder Zeit folgen können und sollten. Das ist einer der vielen schönen Aspekte des agilen Arbeitens: die kontinuierliche Verbesserung. 

Besonders spannend: Manchmal sind Punkte soweit “Done”, bis sich dann der Kunde meldet, der die ganze Lösung in Frage stellt und damit euer Fundament an Annahmen über die Kundenbedürfnisse ins Wanken bringt. In solchen Situationen zeigt sich, ob das Team wirklich den Kundennutzen höher priorisiert hat als den Fortschritt im Ticketsystem.

Eine klare Definition of Done kann Konflikte vermeiden und eure Performance erhöhen. Wenn euch noch weitere Wege zu diesem Ziel interessieren, solltet ihr auch mal in unseren Artikel zur erstaunlichen Wahrheit hinter dem agilen Mindset schauen. Oder eure Retrospektiven damit bereichern, die neusten wissenschaftlichen Erkenntnisse aus der Psychologie zu berücksichtigen.

Genau mit diesem Versprechen haben wir unser Retro Tool Echometer entwickelt. Wenn euch interessiert, wie (und ob) Echometer funktioniert, lest gerne einmal in den Erfahrungsbericht von Holger mit unserem Tool:

Du möchtest dein Team auf ein neues Performance-Level heben? Dabei hilft dir unser Retro Tool. Hier sind die Erfahrungen von Holger damit:

Erfahrungsbericht von Holger zum Remote Retro Tool

Häufige Fragen zur Definition of Done

Was gehört in eine Definition of Done?

In eine Definition of Done gehören alle Qualitätskriterien, die ein Inkrement erfüllen muss, damit es nutzbar ist. Typische Beispiele sind erfüllte Akzeptanzkriterien, Code Review, Tests, Sicherheitsprüfung, Dokumentation und die technische Möglichkeit zur Auslieferung. Welche Punkte gelten, entscheidet das Team für seinen Produktkontext.

Wer erstellt die Definition of Done in Scrum?

Das Scrum-Team entwickelt und pflegt die Definition of Done gemeinsam. Sie sollte nicht von einer einzelnen Rolle als Kontrollliste vorgegeben werden. Organisationen können Mindeststandards festlegen, das Team muss sie aber verstehen und im Alltag anwenden können.

Was ist der Unterschied zwischen Definition of Done und Definition of Ready?

Die Definition of Done beschreibt, wann ein Inkrement fertig und nutzbar ist. Eine Definition of Ready kann dagegen Kriterien für die Vorbereitung eines Arbeitselements enthalten, ist aber kein offizielles Scrum-Artefakt und darf nicht dazu dienen, Verantwortung oder Feedbackschleifen zu verschieben.

Beispiel aus der Praxis: Unsere interne Definition of Done bei Echometer

Eine Definition of Done muss nicht bei Code und Tests enden. Echometer nutzt intern einen umfassenderen Standard, der neben der Funktionalität auch UX, Wartbarkeit, Beobachtbarkeit und die Vorbereitung des Releases berücksichtigt. Das folgende Beispiel zeigt, wie ein Team seine eigenen Qualitätskriterien konkret und überprüfbar machen kann:

Bereich	Beispielhafte Kriterien
Funktionalität	Die spezifizierte Funktion funktioniert, typische Edge Cases sind geprüft, es gibt keine bekannten Fehler, unfertige Funktionen sind per Feature Flag geschützt und relevante Nutzungsdaten werden erfasst.
UX	Leere Zustände, Ladezustände, Berechtigungen, Fehlerbehandlung, Lokalisierung und responsive Darstellung sind berücksichtigt.
Wartbarkeit	Coding Guidelines und relevante Konventionen sind eingehalten, unnötiger Code und bewusst hinterlassene technische Schulden wurden vermieden, und wichtige Informationen für Monitoring und Debugging sind vorhanden.
Deployment	Die Änderung ist produktiv ausgerollt oder bewusst per Feature Flag vorbereitet, Release Notes sind ergänzt und betroffene Stakeholder werden bei Bedarf informiert.

Dieses Beispiel ist natürlich keine allgemeingültige Vorlage. Ihr könnt sie aber als Grundlage verwenden, sie mit eigenen Definitionen ausschmücken, regelmäßig überprüfen und als lebendes Dokument weiterentwickeln.

Quellen

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x