Definition of Done erklärt – Eine Funktion ist „fast fertig“, „eigentlich fertig“ oder „zu 80 % fertig“ – in vielen Teams klingt das vertraut. Genau hier beginnt das Problem: Ohne gemeinsames Verständnis von „fertig“ entstehen Missverständnisse, Nacharbeit und Qualitätsrisiken.
Die Definition of Done schafft Klarheit. Sie legt fest, welche Kriterien ein Ergebnis erfüllen muss, damit es wirklich abgeschlossen ist. Richtig eingeführt, reduziert sie Diskussionen, verbessert Planbarkeit und sichert Qualität – in agilen Teams genauso wie in klassischen Projekten.
Dieser Beitrag erklärt die Definition of Done praxisnah, zeigt typische Fehler und liefert konkrete Beispiele und Vorlagen, wie Sie eine tragfähige DoD für Ihr Team oder Ihre Organisation entwickeln.
Was ist die Definition of Done?
Kurz erklärt:
Die Definition of Done (DoD) ist eine vom Team gemeinsam vereinbarte Liste von Kriterien, die erfüllt sein müssen, damit ein Arbeitsgegenstand (z. B. User Story, Feature, Task, Projekt-Deliverable) als „fertig“ gilt.
Typische Merkmale:
- Gilt für alle Arbeiten eines Teams (nicht für einzelne Stories individuell)
- Ist transparent und für alle sichtbar
- Bezieht sich v. a. auf Qualität, Vollständigkeit und Prüfbarkeit
- Wird gemeinsam definiert, regelmäßig überprüft und angepasst
In Scrum ist die Definition of Done eine formale Vereinbarung rund um Inkremente. Sie lässt sich jedoch genauso in klassischen Projektorganisationen, Kanban-Teams oder Linienabteilungen einsetzen.
Warum eine Definition of Done unverzichtbar ist
Ohne klare Definition, wann etwas „fertig“ ist, passieren immer wieder dieselben Dinge:
- Stories wandern in „Done“, obwohl Tests fehlen
- Fachbereiche reklamieren unvollständige Funktionen
- Go-Lives verzögern sich, weil noch „unsichtbare“ Arbeit ansteht
- Velocity / Durchsatz sind nicht vergleichbar
- Teams reden aneinander vorbei („Das ist doch fertig!“ – „Nein, so nicht.“)
Eine gute Definition of Done löst genau diese Probleme.
Zentrale Vorteile im Überblick
1. Gemeinsames Verständnis von Qualität
- Alle wissen, was „fertig“ fachlich und technisch bedeutet
- Erwartungshaltungen von Stakeholdern werden klar
2. Bessere Planbarkeit
- Realistischere Aufwandsschätzungen
- Weniger versteckte Restarbeiten
- Zuverlässigere Release- und Lieferzusagen
3. Reduzierte Nacharbeit
- Frühzeitige Qualitätssicherung statt spätes Bug-Fixing
- Weniger Eskalationen und Wiedereröffnungen
4. Höhere Transparenz
- Fortschritt wird ehrlich berichtet – kein „Schönrechnen“
- Management erkennt echte Reifegrade von Ergebnissen
5. Grundlage für kontinuierliche Verbesserung
- Teams reflektieren regelmäßig: Reicht unsere DoD?
- Qualitätsstandards wachsen mit der Organisation
Für wen ist die Definition of Done relevant?
Die Definition of Done betrifft nicht nur Entwicklerteams. Sie betrifft die gesamte Wertschöpfungskette:
- Business / Fachbereiche
- Wissen, was sie von einem „fertigen“ Inkrement erwarten können
- Können Abnahmen strukturierter durchführen
- Product Owner / Projektleiter
- Nutzen die DoD, um Backlog Items und Arbeitspakete gezielt zu schneiden
- Treffen informierte Entscheidungen über Release-Reife
- Entwicklungsteams / Fachanwender-Teams
- Arbeiten fokussierter, da Klarheit über Qualitätsanspruch besteht
- Vermeiden technische Schulden, die „später“ erledigt werden sollten
- Management / Führungskräfte
- Bekommen verlässlichere Kennzahlen und Statusberichte
- Können Anforderungen an Compliance, Sicherheit, Dokumentation verankern
Definition of Done vs. Akzeptanzkriterien
Diese beiden Begriffe werden häufig verwechselt oder vermischt. Die Trennung ist wichtig.
Akzeptanzkriterien
- Gelten für einzelne User Stories / Anforderungen
- Beschreiben funktionales Verhalten aus Nutzersicht
- Beantworten: „Wann erfüllt diese Story ihren Zweck?“
- Beispiel:
- „Der Nutzer kann sein Passwort per E-Mail zurücksetzen.“
- „Fehleingaben werden mit einer Fehlermeldung angezeigt.“
Definition of Done
- Gilt für alle Arbeiten eines Teams oder Produkts
- Beschreibt allgemeine Qualitäts- und Fertig-Kriterien
- Beantwortet: „Was muss immer erfüllt sein, damit etwas lieferfähig ist?“
- Beispiel:
- „Code ist im Repository versioniert.“
- „Tests sind automatisiert und grün.“
- „Dokumentation ist aktualisiert.“
Kurzfassung:
Akzeptanzkriterien = „Was soll es können?“
Definition of Done = „Wie gut und wie vollständig muss es sein?“
Typische Inhalte einer Definition of Done
Jede Definition of Done ist kontextabhängig. Es gibt keine universelle Checkliste, die überall passt. Dennoch haben sich typische Kategorien etabliert.
1. Qualität & Tests
- Fachliche Tests durchgeführt und bestanden
- Unit-Tests vorhanden, Mindestabdeckung vereinbart
- Integrationstests für relevante Schnittstellen erfolgreich
- Regressionstests bei kritischen Änderungen durchgeführt
- Explorative Tests bei komplexen Funktionen
2. Code & Architektur
- Code-Review durchgeführt (z. B. 4-Augen-Prinzip)
- Coding-Guidelines eingehalten
- SonarQube / statische Codeanalyse ohne kritische Findings
- Keine bekannten Blocker- oder Major-Bugs offen
- Technische Schulden dokumentiert und bewusst akzeptiert (nicht „vergessen“)
3. Dokumentation
- Technische Dokumentation aktualisiert
- Benutzer-Dokumentation / Hilfetexte angepasst
- relevante Architektur-Diagramme auf dem aktuellen Stand
- Changelog / Release-Notes vorbereitet
4. Betrieb & Sicherheit
- Logging und Monitoring konfiguriert
- Security-Checks (z. B. OWASP-Top-10-relevante Tests) durchgeführt
- Feature-Flags / Rollback-Möglichkeiten vorhanden, wenn notwendig
- Performance-Anforderungen verifiziert (z. B. Response-Zeiten)
5. Fachliche Abnahme & Integration
- Fachliche Abnahme erfolgt oder vorbereitet
- Auswirkungen auf angrenzende Prozesse geprüft
- Schulungsbedarf identifiziert, ggf. initial adressiert
Diese Punkte dienen als Baukasten. Entscheidend ist, dass Sie für Ihr Team bewusst auswählen, was wirklich relevant und realistisch ist.
Wie erstellt man eine gute Definition of Done? (Schritt-für-Schritt)
Viele Teams kopieren fertige Listen aus dem Internet. Das führt selten zu gelebten Standards. Besser: das Team entwickelt seine eigene Definition of Done.
Schritt 1: Startpunkt festlegen
- Klarer Geltungsbereich:
- Gilt die DoD für ein Team, ein Produkt oder mehrere Teams?
- Vereinbaren, für welche Artefakte sie gilt:
- User Stories, Features, Epics, Bugs, ganze Releases?
Schritt 2: Bestehende Praxis sichtbar machen
In einem Workshop (1,5–2 Stunden):
- Fragen Sie das Team:
- „Wann ist eine Story für euch heute ‚fertig‘?“
- „Was passiert tatsächlich, bevor ihr etwas übergebt / live stellt?“
- Sammeln Sie alle Schritte auf Karten / im Whiteboard:
- Testen, Dokumentieren, Reviewen, Deployen, Abstimmen, usw.
Ziel: Die Ist-DoD sichtbar machen – oft überraschend unkoordiniert.
Schritt 3: Kriterien clustern und präzisieren
- Gruppen bilden:
- Tests, Code, Doku, Betrieb, Fachliches, Compliance …
- Dubletten zusammenführen, Unklarheiten konkretisieren:
- „Tests gemacht“ → „Unit- und Integrationstests geschrieben und grün“
- „Doku ok“ → „Benutzer-Doku um neue Funktionen ergänzt“
Wichtig: Formulieren Sie prüfbare Aussagen, keine Schlagworte.
Schritt 4: Realismus-Check
Eine DoD, die niemand erfüllen kann, nützt nichts.
- Priorisieren Sie Kriterien:
- „Muss heute schon gelten“
- „Zielzustand in 3–6 Monaten“
- Für zu ambitionierte Punkte:
- Klare Roadmap definieren („Ab Q3 setzen wir automatisierte Regressionstests voraus“)
Besser eine ehrlich gelebte als eine perfekte, aber ignorierte DoD.
Schritt 5: Verantwortung und Transparenz klären
- Wer ist verantwortlich, dass die DoD eingehalten wird?
- Teams, nicht Einzelpersonen
- Wo ist die DoD dokumentiert?
- Sichtbar am Board, im Wiki, im Projekt-Tool
- Wie oft wird sie überprüft?
- Z. B. in jeder zweiten Retrospektive
- Oder bei größeren Änderungen im Team / Produkt
Schritt 6: Pilotphase und Anpassung
- DoD in 1–2 Sprints / Iterationen bewusst anwenden
- In Review / Retro fragen:
- „Welche Punkte waren hilfreich?“
- „Wo war die DoD zu streng oder zu schwammig?“
- DoD iterativ verbessern, bis sie natürlicher Bestandteil der Arbeit wird
Praxisbeispiele für eine Definition of Done
Beispiel 1: Software-Produktteam (Scrum)
Geltungsbereich: User Stories des Entwicklungsteams
Eine Story ist „Done“, wenn:
- Alle Akzeptanzkriterien erfüllt und getestet sind
- Unit-Tests mit mindestens 70 % Abdeckung für neue Logik existieren
- Integrationstests für betroffene Schnittstellen durchgeführt wurden
- Kein Blocker- oder Major-Bug offen ist
- Code-Review von mindestens einer weiteren Person erfolgt ist
- Code im Main-Branch gemergt und Builds erfolgreich sind
- Logging für relevante Ereignisse implementiert ist
- Benutzer-Dokumentation / Hilfe aktualisiert wurde
- Auswirkungen auf Berechtigungen und Sicherheit geprüft sind
- UI-Texte sprachlich geprüft wurden
- Änderungen im Changelog dokumentiert sind
Beispiel 2: Fachbereich / Non-IT-Team (z. B. HR-Prozess)
Geltungsbereich: Prozessänderungen im HR-Bereich
Eine Prozessänderung ist „fertig“, wenn:
- Ziel und Nutzen der Änderung schriftlich definiert sind
- Auswirkungen auf andere Prozesse dokumentiert sind
- Genehmigungen der relevanten Stakeholder vorliegen
- Arbeitsanweisungen und Vorlagen aktualisiert wurden
- Mitarbeitende informiert und ggf. geschult wurden
- Kontrollmechanismus definiert ist (z. B. KPIs, Audits)
- Go-Live-Datum und Verantwortliche festgelegt wurden
So wird sichtbar: Die Definition of Done ist nicht auf IT beschränkt. Sie lässt sich in jeder Wissensarbeit anwenden.
Wie Sie die Definition of Done im Alltag verankern
Viele DoDs scheitern im Alltag, weil sie zwar existieren, aber niemand sie aktiv nutzt. Damit das nicht passiert, helfen diese konkreten Hebel:
1. DoD im Backlog Refinement nutzen
- Beim Schneiden von User Stories / Arbeitspaketen:
- „Können wir all diese DoD-Kriterien in einem Sprint realistisch erfüllen?“
- Wenn nicht:
- Story / Paket kleiner schneiden
- Oder bewusst eine Ausnahme vereinbaren und dokumentieren
2. DoD im Daily Stand-up sichtbar halten
- Visualisierung im Board / Tool:
- Spalte „Definition of Done“ mit Checkliste
- Im Daily gezielt fragen:
- „Welche DoD-Punkte fehlen noch für diese Story?“
So verlagern Sie den Fokus von „Task-Checklisten“ auf Ergebnisqualität.
3. DoD in Reviews und Abnahmen anwenden
- Vor einer Abnahme:
- Checkliste einmal durchgehen
- Nur Ergebnisse vorstellen, die die DoD erfüllen
- Wenn Kriterien bewusst offen bleiben:
- Transparent machen, was noch fehlt
- Klar entscheiden: „Trotzdem live?“ oder „Zurück ins Backlog“
4. DoD in der Retrospektive reflektieren
Leitfragen:
- „War unsere DoD in diesem Sprint hilfreich oder hinderlich?“
- „Gab es Überraschungen trotz ‚Done‘?“
- „Welche Qualitätsprobleme hätten wir mit einer besseren DoD vermeiden können?“
Dann gezielt anpassen: punktuell ergänzen, streichen, präzisieren.
Häufige Fehler bei der Definition of Done – und wie Sie sie vermeiden
Fehler 1: DoD als reine Formalie betrachten
Symptom: „Wir haben eine DoD im Wiki, aber niemand schaut hinein.“
Abhilfe:
- DoD im Board / Tool integrieren
- In Meetings aktiv nutzen
- Verantwortliche benennen, die auf Einhaltung achten (z. B. Scrum Master, Projektleiter – moderierend, nicht polizeilich)
Fehler 2: Zu generische oder unklare Formulierungen
Beispiele:
- „Qualität gesichert“
- „Alles getestet“
- „Doku gemacht“
Abhilfe:
- Konkrete, prüfbare Aussagen formulieren:
- „Unit- und Integrationstests wurden ausgeführt und sind grün.“
- „Benutzer-Doku um neue Screenshots ergänzt.“
Fehler 3: Perfektionismus
DoD mit zwanzig Punkten, die real nie alle erfüllt werden.
Abhilfe:
- Minimal sinnvolles Set definieren
- Klar zwischen „heute MUSS“ und „später SOLL“ unterscheiden
- Breite Akzeptanz im Team einholen, statt Top-down-Liste zu diktieren
Fehler 4: DoD nur technisch denken
Nur Entwicklerkriterien, kein Blick auf Fachlichkeit, Betrieb, Sicherheit, Compliance.
Abhilfe:
- Fachbereiche, Betrieb, Security, Compliance in die Erarbeitung einbinden
- DoD-Kriterien auch auf diese Dimensionen ausweiten
Fehler 5: DoD nie anpassen
Die erste Version bleibt Jahre unverändert, obwohl sich Technologie, Produkte und Organisation entwickeln.
Abhilfe:
- Fixer Termin für regelmäßigen Review (z. B. halbjährlich)
- DoD als lebendes Artefakt behandeln
Skalierung: Definition of Done in größeren Organisationen
In größeren Unternehmen mit mehreren Teams stellen sich zusätzliche Fragen:
Gemeinsame vs. teamindividuelle Definition of Done
- Organisationsebene:
- Mindeststandards, die für alle Teams gelten (z. B. Security, Compliance, Dokumentationspflichten)
- Teamebene:
- Ergänzende Kriterien, die auf Technologie, Domäne oder Arbeitsweise zugeschnitten sind
So verbinden Sie Governance mit Autonomie.
Harmonisierung über Teams hinweg
- Regelmäßige Austauschformate:
- Community of Practice
- Chapter-Meetings
- Gemeinsame Weiterentwicklung:
- „Was ist unser organisationweiter Mindeststandard?“
- „Wo können Teams bewusst höhere Standards setzen?“
Definition of Done für Epics und Releases
Neben der DoD auf Story-Ebene helfen zusätzliche Ebenen:
- Epic-DoD:
- Alle Stories abgeschlossen und deployed
- End-to-End-Prozess getestet
- Fachkonzept und Prozessdokumentation angepasst
- Release-DoD:
- Release-Notes erstellt
- Rollback-Strategie getestet
- Monitoring-Dashboards angepasst
- Support-/Service-Teams informiert und vorbereitet
So wird die Definition of Done zu einem Rahmenwerk, das von der kleinsten Story bis zum großen Release für Klarheit sorgt.
Konkrete Checkliste: So prüfen Sie Ihre Definition of Done
Nutzen Sie die folgenden Fragen, um Ihre bestehende oder geplante DoD zu evaluieren:
- Ist sie für alle sichtbar und leicht zugänglich?
- Ist klar, für welche Artefakte sie gilt? (Stories, Features, Epics, Releases, …)
- Sind alle Kriterien konkret und überprüfbar formuliert?
- Deckt sie fachliche, technische, betriebliche und dokumentarische Aspekte ab?
- Ist sie realistisch im Alltag erfüllbar?
- Ist geklärt, wer auf Einhaltung achtet?
- Ist geregelt, wann und wie sie angepasst wird?
Wenn Sie mehrere Fragen mit „Nein“ beantworten, lohnt sich ein gezielter Überarbeitungs-Workshop.
Fazit: Definition of Done als Hebel für Qualität und Verlässlichkeit
Eine gute Definition of Done ist mehr als eine Liste im Wiki. Sie ist eine gelebte Vereinbarung, die Klarheit schafft – für Teams, Stakeholder und Management.
Sie…
- macht Qualität messbar
- verbessert Planbarkeit und Verlässlichkeit
- reduziert Nacharbeit und Eskalationen
- gibt Teams einen Rahmen, in dem sie eigenverantwortlich handeln können
Je komplexer Ihre Produkte, Prozesse und Organisation, desto wichtiger wird eine saubere, gemeinsam getragene Definition of Done.
Wenn Sie Ihre bestehende DoD schärfen oder eine tragfähige Definition of Done für mehrere Teams aufsetzen möchten und dabei externe Moderation oder einen methodischen Sparringspartner suchen, können spezialisierte Beratungen wie PURE Consultant Sie dabei unterstützen, diesen Qualitätsrahmen effektiv und nachhaltig in Ihrer Organisation zu verankern.