Definition of Done: Der vollständige Leitfaden für Qualitätsstandards in Agile und Scrum

Die Definition of Done gehört zu den zentralen Konzepten moderner agiler Produktentwicklung und spielt insbesondere im Framework Scrum eine entscheidende Rolle. Sie beschreibt eindeutig, wann eine Aufgabe, ein Feature oder ein Produktinkrement tatsächlich abgeschlossen ist und den Qualitätsanforderungen des Teams entspricht. In einer Umgebung, in der Unternehmen immer schneller neue Funktionen veröffentlichen müssen, entstehen ohne klare Abschlusskriterien häufig Missverständnisse, technische Schulden und instabile Releases. Eine klar formulierte Definition of Done stellt sicher, dass jede ausgelieferte Funktion denselben Qualitätsstandard erfüllt. Studien zur agilen Reife von Organisationen zeigen im Jahr 2026, dass Teams mit einer dokumentierten Definition of Done im Durchschnitt 30 % weniger Produktionsfehler melden als Teams ohne formalisierte Qualitätsdefinition.

Was ist die Definition of Done in Agile und Scrum

Die Definition of Done (DoD) ist eine klar dokumentierte Liste von Kriterien, die festlegt, wann ein Arbeitselement vollständig abgeschlossen ist. Im Kontext von Scrum beschreibt sie den Zustand eines Produktinkrements, wenn dieses alle definierten Qualitätsanforderungen erfüllt. Diese Kriterien werden von Team und Organisation gemeinsam festgelegt, um sicherzustellen, dass jedes entwickelte Feature denselben Qualitätsstandard erfüllt. Ohne eine solche Definition könnten Teammitglieder unterschiedliche Auffassungen davon haben, wann Arbeit wirklich abgeschlossen ist, was zu Inkonsistenzen und Qualitätsproblemen führen würde.

Eine präzise Definition of Done schafft Transparenz im Entwicklungsprozess und ermöglicht es allen Beteiligten, den Fortschritt eines Produkts objektiv zu bewerten. Wenn ein Backlog-Element nicht alle Kriterien der DoD erfüllt, gilt es nicht als abgeschlossen und kann daher nicht als Teil des fertigen Produktinkrements betrachtet werden. Diese klare Regel hilft Teams dabei, ihre Qualitätsstandards konsequent einzuhalten und sicherzustellen, dass jedes Sprint-Ergebnis tatsächlich nutzbar und potenziell auslieferbar ist.

Rolle der Definition of Done im Scrum-Framework

Im Scrum-Framework ist die Definition of Done eng mit dem Artefakt Increment verbunden. Am Ende jedes Sprints muss das Entwicklungsteam ein potenziell auslieferbares Produktinkrement liefern, das vollständig der Definition of Done entspricht. Dadurch wird sichergestellt, dass das Produkt kontinuierlich verbessert wird und dass jedes Sprint-Ergebnis einen realen Mehrwert darstellt. Dieser Ansatz unterstützt das empirische Prinzip von Scrum, das auf Transparenz, Überprüfung und Anpassung basiert.

Die Definition of Done fördert zudem eine gemeinsame Verantwortung für Qualität innerhalb des Teams. Da alle Teammitglieder dieselben Abschlusskriterien kennen und akzeptieren, können sie sicherstellen, dass keine wichtigen Entwicklungsschritte ausgelassen werden. Diese gemeinsame Qualitätsbasis verhindert, dass unfertige Funktionen ausgeliefert werden und stärkt die Stabilität des gesamten Produkts.

Warum die Definition of Done entscheidend für Produktqualität ist

Eine klar definierte Definition of Done fungiert als Qualitätskontrolle im Entwicklungsprozess. Sie verhindert, dass unfertige oder unzureichend getestete Funktionen in das Produkt integriert werden. Indem sie zwingende Aktivitäten wie Tests, Code-Reviews oder Dokumentationsaktualisierungen vorschreibt, stellt die DoD sicher, dass jede Funktion vor der Auslieferung ein Mindestmaß an Qualität erreicht. Dadurch sinkt das Risiko von Fehlern in der Produktion erheblich.

Die Definition of Done verbessert auch die Zusammenarbeit innerhalb eines cross-funktionalen Agile-Teams. Entwickler, Tester und Product Owner teilen dieselbe Vorstellung davon, wann Arbeit wirklich abgeschlossen ist. Diese gemeinsame Grundlage reduziert Missverständnisse und sorgt dafür, dass sich alle Teammitglieder auf die gleichen Qualitätsziele konzentrieren. Dadurch wird der Sprint-Prozess effizienter und die Planbarkeit der Releases verbessert sich deutlich.

Reduzierung technischer Schulden durch die Definition of Done

Technische Schulden entstehen häufig, wenn Teams wichtige Qualitätsmaßnahmen aus Zeitdruck überspringen. Eine starke Definition of Done verhindert dieses Problem, indem sie bestimmte Aktivitäten obligatorisch macht. Dazu gehören zum Beispiel automatisierte Tests, Peer-Reviews des Codes oder Sicherheitsprüfungen. Diese Maßnahmen stellen sicher, dass der entwickelte Code langfristig wartbar und stabil bleibt.

Wenn solche Aktivitäten ausgelassen werden, können Teams kurzfristig schneller liefern, doch langfristig steigen Wartungsaufwand und Fehleranfälligkeit deutlich an. Durch die Integration dieser Aufgaben in die Definition of Done wird verhindert, dass wichtige Qualitätsschritte übergangen werden. Das Ergebnis ist eine stabilere technische Basis, auf der Teams nachhaltiger neue Funktionen entwickeln können.

Definition of Done vs. Acceptance Criteria vs. Definition of Ready

In agilen Entwicklungsprozessen existieren mehrere Konzepte, die häufig mit der Definition of Done verwechselt werden. Dazu gehören insbesondere die Acceptance Criteria sowie die Definition of Ready. Obwohl diese Begriffe miteinander verbunden sind, erfüllen sie unterschiedliche Funktionen im Entwicklungsprozess und greifen an verschiedenen Stellen des Workflows ein.

Die Definition of Ready stellt sicher, dass ein Backlog-Eintrag ausreichend vorbereitet ist, bevor die Entwicklung beginnt. Acceptance Criteria definieren hingegen die funktionalen Anforderungen, die ein Feature erfüllen muss, um die Erwartungen der Nutzer zu erfüllen. Die Definition of Done kommt am Ende des Entwicklungsprozesses zum Einsatz und stellt sicher, dass alle technischen, funktionalen und operativen Anforderungen erfüllt sind.

Zusammenspiel dieser drei Konzepte

Gemeinsam bilden diese drei Konzepte eine strukturierte Grundlage für die agile Produktentwicklung. Die Definition of Ready sorgt dafür, dass Aufgaben klar definiert sind, bevor die Entwicklung startet. Acceptance Criteria legen fest, welche Ergebnisse eine Funktion liefern muss. Die Definition of Done stellt schließlich sicher, dass das Ergebnis auch technisch vollständig und qualitativ hochwertig umgesetzt wurde.

• Definition of Ready: Kriterien, die erfüllt sein müssen, bevor die Entwicklung beginnt.
• Acceptance Criteria: Funktionale Anforderungen einer User Story.
• Definition of Done: Qualitätsstandards für abgeschlossene Arbeit.

Wie man eine effektive Definition of Done erstellt

Die Erstellung einer effektiven Definition of Done erfordert eine enge Zusammenarbeit innerhalb des Agile-Teams. Ziel ist es, jene Aktivitäten zu identifizieren, die unbedingt abgeschlossen sein müssen, bevor eine Aufgabe als fertig gilt. Eine gute DoD sollte nicht unnötig komplex sein, sondern klare und praktikable Qualitätskriterien enthalten, die im Arbeitsalltag des Teams konsequent angewendet werden können.

Oft beginnt die Erstellung einer DoD mit einem Workshop, in dem das Team gemeinsam festlegt, welche Schritte notwendig sind, um eine Funktion in ein auslieferbares Produktinkrement zu verwandeln. Dazu gehören beispielsweise Tests, Sicherheitsprüfungen, Dokumentation oder Deployment-Validierungen. Durch diese gemeinsame Definition entsteht ein realistischer Standard, der von allen Teammitgliedern getragen wird.

Schritte zur Entwicklung einer robusten DoD

Eine stabile Definition of Done basiert auf einer strukturierten Analyse der Qualitätsanforderungen eines Produkts. Teams sollten dabei sowohl technische Anforderungen als auch organisatorische Vorgaben berücksichtigen. Erfahrungen aus früheren Projekten und Produktionsproblemen können wertvolle Hinweise liefern, welche Kriterien unbedingt Teil der DoD sein sollten.

1. Festlegen der minimalen Qualitätsanforderungen.
2. Integration wichtiger Entwicklungspraktiken wie Code-Reviews.
3. Definition von Test- und Validierungsprozessen.
4. Dokumentation und Sichtbarmachung der Definition of Done.
5. Regelmäßige Überprüfung und Anpassung der DoD.

Beispiele für Kriterien einer Definition of Done

Die konkrete Ausgestaltung einer Definition of Done hängt stark vom jeweiligen Projektkontext ab. Teams, die SaaS-Produkte entwickeln, setzen häufig auf automatisierte Tests und Continuous Integration, während Projekte in regulierten Branchen zusätzliche Compliance- und Sicherheitsprüfungen enthalten. Trotz dieser Unterschiede existieren einige Kriterien, die in den meisten modernen DoD-Definitionen zu finden sind.

Leistungsstarke Agile-Teams kombinieren technische Validierung, funktionale Prüfung und betriebliche Vorbereitung in ihrer Definition of Done. Dadurch stellen sie sicher, dass jedes ausgelieferte Inkrement sofort einsatzbereit ist und keine zusätzlichen Nacharbeiten erforderlich sind. Dieser strukturierte Ansatz erhöht die Zuverlässigkeit von Releases erheblich.

• Code erfolgreich implementiert und kompiliert.
• Unit-Tests und Integrationstests bestanden.
• Code-Review durch ein Teammitglied durchgeführt.
• Technische Dokumentation aktualisiert.
• Deployment in einer Testumgebung validiert.
• Akzeptanzkriterien vom Product Owner bestätigt.

Häufige Fehler bei der Definition of Done

Obwohl sie ein zentrales Element agiler Qualitätssicherung ist, wird die Definition of Done in vielen Organisationen falsch angewendet. Ein häufiger Fehler besteht darin, eine DoD zu formulieren, die zu ungenau ist und Interpretationsspielraum lässt. Wenn die Kriterien nicht eindeutig definiert sind, können Teammitglieder Aufgaben als abgeschlossen betrachten, obwohl wichtige Arbeitsschritte fehlen.

Ein weiteres Problem entsteht, wenn Teams die Definition of Done umgehen, um Sprint-Ziele schneller zu erreichen. Dieses Verhalten kann kurzfristig Zeit sparen, führt jedoch häufig zu instabilen Releases und einer wachsenden technischen Schuld. Teams, die ihre DoD konsequent einhalten, erzielen langfristig stabilere Produkte und reduzieren den Aufwand für nachträgliche Fehlerkorrekturen.

Anzeichen für eine ineffektive Definition of Done

Mehrere Warnsignale können darauf hinweisen, dass eine Definition of Done nicht ausreichend wirksam ist. Diese Symptome treten häufig auf, wenn Funktionen nach der Fertigstellung erneut überarbeitet werden müssen oder wenn Releases regelmäßig Fehler enthalten. Durch die Analyse dieser Muster können Teams ihre DoD verbessern und ihre Entwicklungsprozesse stabilisieren.

• Features gelten als fertig, sind aber nicht deploybar.
• Häufige Fehler nach jedem Sprint.
• Unvollständige oder veraltete Dokumentation.
• Fehlende automatisierte Tests.
• Schwierigkeiten, ein stabiles Sprint-Inkrement zu liefern.

Definition of Done im Kontext von DevOps

Die zunehmende Verbreitung von DevOps hat den Umfang der Definition of Done deutlich erweitert. Moderne Entwicklungsteams arbeiten mit automatisierten Deployment-Pipelines und kontinuierlicher Integration, wodurch auch operative Aspekte Teil der Qualitätsdefinition werden. Die DoD umfasst deshalb nicht mehr nur Entwicklungsaufgaben, sondern auch betriebliche Anforderungen.

DevOps-Teams integrieren häufig Monitoring-Konfigurationen, Logging-Standards und Rollback-Strategien in ihre Definition of Done. Diese Kriterien stellen sicher, dass neue Funktionen nach der Veröffentlichung überwacht und bei Bedarf schnell zurückgerollt werden können. Durch diese Integration wird die DoD zu einem umfassenden Qualitätsrahmen für Entwicklung und Betrieb.

Die Definition of Done kontinuierlich verbessern

Eine Definition of Done sollte sich kontinuierlich weiterentwickeln, da sich sowohl Produkte als auch Entwicklungsprozesse ständig verändern. Agile Teams überprüfen ihre DoD regelmäßig, um sicherzustellen, dass sie den aktuellen technischen und organisatorischen Anforderungen entspricht. Diese iterative Anpassung ermöglicht es, die Qualitätsstandards schrittweise zu erhöhen, ohne die Liefergeschwindigkeit zu beeinträchtigen.

Viele Teams passen ihre Definition of Done während der Sprint-Retrospektiven an. Dort analysieren sie Probleme aus vergangenen Iterationen und entscheiden, ob neue Qualitätskriterien eingeführt werden sollten. Wenn beispielsweise ein Produktionsfehler auftritt, kann das Team beschließen, zusätzliche Tests oder Validierungen in die DoD aufzunehmen, um ähnliche Probleme künftig zu vermeiden.

SEO-FAQ zur Definition of Done

Wer definiert die Definition of Done in Scrum

Im Scrum-Framework wird die Definition of Done in der Regel vom Entwicklungsteam erstellt, da es die notwendigen Schritte zur Umsetzung der Produktfunktionen am besten kennt. Allerdings können auch organisatorische Standards berücksichtigt werden, etwa in Bezug auf Sicherheit, Compliance oder technische Richtlinien. Das Team muss diese Anforderungen in eine praktische Definition übersetzen, die im Sprint-Alltag angewendet werden kann.

Ist eine Definition of Done in Scrum verpflichtend

Die Definition of Done gilt als grundlegender Bestandteil des Scrum-Frameworks, da sie sicherstellt, dass jedes Sprint-Inkrement denselben Qualitätsstandard erfüllt. Ohne eine klare DoD wäre es schwierig zu beurteilen, ob Arbeit tatsächlich abgeschlossen ist. Teams mit einer klar dokumentierten Definition of Done verfügen in der Regel über stabilere Releases und eine höhere Transparenz im Entwicklungsprozess.

Was ist der Unterschied zwischen Definition of Done und Acceptance Criteria

Acceptance Criteria beschreiben die funktionalen Anforderungen einer User Story und definieren, welche Ergebnisse eine Funktion liefern muss, um die Erwartungen der Nutzer zu erfüllen. Die Definition of Done hingegen legt die allgemeinen Qualitätsstandards fest, die jedes Arbeitselement erfüllen muss, bevor es als abgeschlossen gilt. Während Acceptance Criteria für jede User Story individuell sind, gilt die Definition of Done für alle Aufgaben im Produkt-Backlog.

Lesen Sie auch: Burndown Chart.