Definition of Done: Was es ist und wie man es verwendet

Galen Low

on Jun 15, 2026

Ich habe gelernt, dass sich die meisten Debatten über die Definition of Done nicht um die Arbeit selbst drehen, sondern um Erwartungen. Hier erfahren Sie, wie Sie eine Definition of Done erstellen, die Qualität, Vertrauen und Lieferung aufeinander abstimmt.

Key Takeaways

Qualitätskonsistenz: Die Etablierung einer gemeinsamen Definition of Done verhindert Missverständnisse und verbessert die Arbeitsqualität im Team.

Verbesserte Prognosen: Eine klare Definition unterstützt eine präzise Velocity-Prognose und eine bessere Projektplanung.

Häufige Fallstricke: Vermeiden Sie es, die Definition zu detailliert zu gestalten oder ihre Durchsetzung zu vernachlässigen – beides kann zu Problemen führen.

Praktische Schritte: Der Artikel beschreibt konkrete Schritte, wie agile Teams eine erfolgreiche Definition of Done erstellen.

Die Definition of Done (DoD) ist der gemeinsam genutzte Standard, der festlegt, wann eine Arbeit wirklich abgeschlossen ist. Sie hilft, Qualitätslücken, Nacharbeiten und unangenehme Überraschungen am Ende des Sprints zu vermeiden. Ich habe erlebt, wie Entwicklungsteams das Vertrauen verlieren, Termine verpassen und unnötige Konflikte entstehen, weil jeder eine andere Vorstellung von „fertig“ hatte.

In diesem Leitfaden erfahren Sie, wie Sie eine Definition of Done erstellen, die Ihr agiles Team aufeinander abstimmt, die Vorhersagbarkeit verbessert und die Qualität stärkt – inklusive praktischer Beispiele, Vorlagen und typischer Fehler, die Sie vermeiden sollten.

Was ist die Definition of Done?

Die Definition of Done ist eine formale, gemeinsam vereinbarte Sammlung von Kriterien, die ein Product Backlog Item oder ein Inkrement erfüllen muss, bevor das Team es als abgeschlossen und potenziell auslieferbar betrachtet. Sehen Sie sie als Qualitätsvertrag, auf den sich Ihr Team bei jeder Aufgabe einigt – unabhängig von deren Größe oder Komplexität.

Hier sind die wichtigsten Merkmale einer effektiven Definition of Done:

Transparenz: Alle Teammitglieder und wichtige Stakeholder können sie jederzeit einsehen, lesen und darauf Bezug nehmen.
Messbarkeit: Jedes Kriterium ist binär. Die Arbeit erfüllt es oder sie erfüllt es nicht. Die Grenzwerte für quantitative Kriterien sollten jedoch sorgfältig gewählt werden. Ein Code-Coverage-Ziel von 80 % ist in der Durchsetzung binär, aber ob Sie 80 % statt 70 % oder 90 % wählen, sollte eine bewusste Entscheidung sein.
Allgemeines Verständnis: Jedes Mitglied des Scrum-Teams muss jedes Kriterium auf die gleiche Weise interpretieren können.
Konsequente Anwendung: Die gleiche Checkliste muss bei jedem Liefergegenstand und jedem Product Backlog Item angewandt werden.
Erreichbar innerhalb eines Sprints: Die Kriterien sollten realistisch sein, sodass das Team sie innerhalb eines Sprints oder einer Iteration erfüllen kann.

In Softwareentwicklungsprojekten liegt die Verantwortung für die Definition of Done in der Regel bei den Entwicklern, da sie für die Einhaltung verantwortlich sind. Trotzdem sollten sowohl der Product Owner als auch der Scrum Master mitwirken.

Falls Ihre Organisation eigene Standards für die Definition of Done hat, muss jedes Scrum-Team diese mindestens einhalten. Teams können jederzeit strengere Kriterien hinzufügen, aber niemals unter das organisatorische Mindestmaß gehen.

Warum die Definition of Done wichtig ist

Eine klare Definition of Done ist entscheidend, da sie verhindert, dass teilweise erledigte Arbeit untergeht, und sie bildet einen gemeinsamen Qualitätsstandard.

Weitere Gründe, warum eine gemeinsame Definition of Done wichtig ist:

Fungiert als eingebaute Qualitätskontrolle: Jeder Punkt muss die gleichen Anforderungen erfüllen, bevor er abgeschlossen ist. Das verhindert, dass halbfertige Arbeit in Ihr Produktinkrement gelangt und sich als technische Schulden anhäuft.
Beseitigt Unklarheiten: Wenn das Team eine einheitliche Definition teilt, entstehen keine Situationen, in denen widersprüchliche Definitionen die Geschwindigkeit oder Qualität der Arbeit beeinflussen. Eine gemeinsame Definition of Done bedeutet weniger Konflikte, weniger Überraschungen und klarere Demos.
Verbessert die Prognosefähigkeit: Wenn „fertig“ in jedem Sprint das Gleiche bedeutet, können Sie die Geschwindigkeit zuverlässig voraussagen und Releases planen, ohne Puffer einzuplanen, um Nacharbeit auszugleichen.
Stärkt das Vertrauen der Stakeholder: Wenn Product Owner, Führungskräfte und externe Stakeholder sehen, dass Ihr Team einen klaren Qualitätsstandard durchsetzt, vertrauen sie Ihren Ergebnissen.
Verhindert Integrationschaos: Wenn Sie so arbeiten, dass das Team seine Arbeit in ein gemeinsames Inkrement integriert, ist das gemeinsame Verständnis der Definition of Done die Basis für konsistente, auslieferbare Inkremente.

Wie Sie eine Definition of Done erstellen

Hier sind die wichtigsten Schritte zur Erstellung einer Definition of Done.

Untersuchen Sie Ihren aktuellen Arbeitsablauf: Zeichnen Sie jeden Schritt auf, den Ihre Arbeit bereits durchläuft, bevor sie in die Produktion gelangt. Sprechen Sie mit Entwicklern, Testern, Designern und allen, die an der Arbeit beteiligt sind. Sie werden informelle Qualitätsschritte entdecken, die formalisiert werden sollten.
Bestimmen Sie nicht verhandelbare Qualitätskriterien: Legen Sie fest, welche Aktivitäten für jede Arbeit unbedingt erforderlich sind. Dazu gehören typischerweise Code-Reviews, automatisierte Tests, Aktualisierungen der Dokumentation und Sicherheitsüberprüfungen. Seien Sie ehrlich, was aktuell eventuell ausgelassen wird.
Erstellen Sie die Checkliste gemeinsam: Bringen Sie das gesamte Team zusammen und erarbeiten Sie die Liste gemeinschaftlich auf einem Whiteboard oder in einem geteilten Dokument, in dem jeder in Echtzeit Punkte hinzufügen, hinterfragen und verfeinern kann. Eine im Konsens verabschiedete Definition of Done hält dem Druck deutlich besser stand als eine, die gegen Widerstand abgestimmt wurde.
Mit Unternehmensstandards abgleichen: Vergleichen Sie Ihren Entwurf mit bestehenden unternehmensweiten Qualitätsrichtlinien, regulatorischen Vorgaben oder Industriestandards, die Ihr Produkt erfüllen muss. Falls es in Ihrer Organisation bereits eine Basis-Definition of Done gibt, nutzen Sie diese als Ausgangspunkt und bauen Sie darauf auf.
Machen Sie sie sichtbar: Veröffentlichen Sie die Definition dort, wo Ihr Team täglich arbeitet – zum Beispiel als Poster an der Wand, angeheftete Nachricht in Slack oder als Panel im Projektmanagement-Tool.
Verpflichten Sie sich zur Anwendung: Eine Definition of Done, die bei nahenden Deadlines außer Kraft gesetzt wird, ist schlimmer als gar keine, da sie ein falsches Gefühl von Qualität entstehen lässt.

Beispiele für eine Definition of Done

Hier sind einige Beispiele für Definitionen of Done für verschiedene Projekttypen:

Definition of Done für Softwareentwicklungs-Projekte

Softwareprojekte stellen sich einer Vielzahl von Qualitätsrisiken: Fehler, Sicherheitslücken, Rückschritte bei der Performance und Integrationsprobleme. Die Definition of Done für ein Software-Team muss den vollständigen Weg vom Code bis zum auslieferbaren Stand abdecken.

Das könnte zum Beispiel so aussehen:

Gesamter Code geschrieben und mindestens durch einen weiteren Entwickler geprüft
Unittests bestanden mit vereinbarter Abdeckungsrate
Integrationstests in der CI/CD-Pipeline erfolgreich
Keine offenen Bugs mit kritischer oder hoher Priorität
Technische Dokumentation entsprechend den Änderungen aktualisiert
Code in den Haupt-Branch gemergt
Product Owner hat die Arbeit geprüft und abgenommen
Performance-Benchmarks wurden gemäß vereinbarter Grenzwerte erfüllt

Definition of Done für Marketing-Projekte

Marketing-Arbeit hat häufig Compliance-, Marken- und Messaspekte, die sich von der Softwareentwicklung unterscheiden.

So könnte eine Definition of Done für ein Marketing-Projekt aussehen:

Content vom Rechts-Team geprüft und genehmigt
SEO-Checkliste abgeschlossen, inklusive Meta-Beschreibungen, Alt-Texten und internen Links
Alle Assets ins CMS hochgeladen und korrekt formatiert
Analytics-Tracking im Staging-Umfeld konfiguriert und verifiziert
Finaler Text von einem zweiten Teammitglied Korrektur gelesen
Abhakliste für den Kampagnenstart vom Teamlead abgenommen

Definition of Done für Design-Projekte

Designteams benötigen eine Definition of Done, die die Brücke schlägt zwischen kreativer Absicht und technischer Übergabe. Ohne eine solche erreicht das Design die Entwicklung unvollständig, mit fehlenden Spezifikationen, unüberprüftem responsiven Verhalten oder Barrierefreiheitslücken, die zu spät erkannt werden.

Hier ein Beispiel für eine Definition of Done bei einem Design-Projekt:

Design nach Barrierefreiheitsstandards gemäß WCAG 2.2 überprüft
Übergabedatei im vereinbarten Tool mit allen Spezifikationen, Assets und Anmerkungen vorbereitet
Abnahme durch Stakeholder eingeholt und dokumentiert
Design-System-Komponenten aktualisiert, sofern neue Muster eingeführt wurden
Responsives Verhalten an den vereinbarten Breakpoints validiert

Definition of Done vs. Abnahmekriterien

Die Definition of Done ist Ihr teamweites Qualitätsniveau, während Abnahmekriterien funktionsbezogene Anforderungen auf Feature-Ebene sind.

Betrachte die Definition of Done als die Grundlage, die universell gilt, und Akzeptanzkriterien als individuell für jedes Sprint-Backlog- oder Product-Backlog-Element einzigartig. Ein Product-Backlog-Element ist abgeschlossen, wenn es sowohl seine Akzeptanzkriterien als auch die Definition of Done des Teams erfüllt.

Aspekt	Definition of Done	Akzeptanzkriterien
Umfang	Gilt für jedes Product-Backlog-Element und Inkrement	Spezifisch für eine einzelne User Story oder ein Product-Backlog-Element
Verantwortung	Im Besitz der Entwickler, mit Beiträgen vom gesamten Scrum-Team	Vom Product Owner erstellt oder gemeinsam mit ihm
Spezifizität	Generelle Qualitätsstandards für alle Arbeiten	Detaillierte funktionale Anforderungen für ein Arbeitspaket
Häufigkeit der Änderung	Ändert sich selten; wird während Sprint-Retrospektiven aktualisiert	Ändert sich mit jeder neuen User Story
Prüfpunkt	Wird überprüft, bevor ein Element als abgeschlossen gilt	Während Story-Review oder Akzeptanztests verifiziert

Häufige Fallstricke und Fehler

Hier sind einige häufige Fehler, die du bei der Erstellung deiner Definition of Done vermeiden solltest:

Punkte überspringen, um schneller voranzukommen: Teams, die unter Zeitdruck stehen, lassen oft Kriterien wie Sicherheits-Reviews, Barrierefreiheitstests oder Dokumentation weg. Das führt zu versteckter technischer Schuld, die später in Form von Fehlern, Nacharbeit oder Compliance-Problemen zutage tritt.
Die Checkliste zu detailliert gestalten: Eine übermäßig detaillierte Definition of Done wird zu einer bürokratischen Belastung. Wenn deine Checkliste 30 Punkte umfasst und Entwickler mehr Zeit mit dem Abhaken von Kästchen verbringen als mit dem Entwickeln von Software, bist du zu weit gegangen. Sei konkret genug, dass es Sinn ergibt, aber allgemein genug, um praxistauglich zu bleiben.
Die Definition of Done für jede Story ändern: Der Sinn der Definition of Done ist Konsistenz. Funktionsspezifische Bedingungen gehören in die Akzeptanzkriterien, nicht in die Definition of Done.
Sie nie zu überprüfen: Eine Definition of Done sollte sich weiterentwickeln, wenn sich eure Arbeitsweise verbessert, eure Tools ändern oder euer Produkt wächst. Ich empfehle, sie mindestens einmal im Quartal in Retrospektiven zu prüfen und anzupassen, wenn das Team Lücken oder Probleme feststellt.
Sie nicht durchzusetzen: Eine Definition, die ignoriert wird, wenn jemand Wichtiges es verlangt, ist nutzlos. Die Aufgabe des Scrum Masters ist es, die Definition zu schützen, auch wenn ein Stakeholder etwas veröffentlichen will, das den Qualitätsmaßstab nicht erfüllt. Werden Kriterien routinemäßig übergangen, verliert das Team das Vertrauen in den Standard und nimmt ihn nicht mehr ernst.
"Done" mit "ausgerollt" verwechseln: Die Definition of Done legt fest, ob ein Inkrement veröffentlichbar ist, nicht, ob es bereits ausgeliefert wurde. Ein Product-Backlog-Element kann abgeschlossen sein, ohne ausgerollt zu sein. Füge "in Produktion ausgerollt" nur in deine Definition of Done hinzu, wenn euer Team tatsächlich den gesamten Release-Prozess verantwortet.
Sie nicht zu beachten: Viele Teams haben technisch gesehen eine Definition of Done, aber wenn sie niemand seit ihrer Erstellung vor sechs Monaten angesehen hat, dient sie nicht mehr als Qualitätsmaßstab.

Wie geht es weiter?

Baue auf deinen agilen Prozessen und Arbeitsweisen auf – mit praktischen Tools, Vorlagen und Expertenwissen durch eine kostenlose DPM-Mitgliedschaft – und stärke die Systeme, die Teams dabei helfen, kontinuierlich qualitativ hochwertige Arbeit zu liefern.