Definition of Done im Scrum – Wer in agilen Projekten ernsthaft verlässlich liefern will, kommt an einer sauberen Definition of Done (DoD) nicht vorbei. Trotzdem bleibt sie in vielen Organisationen vage, weichgespült oder wird nach ein paar Sprints gar nicht mehr beachtet. Die Folgen: unterschiedliche Qualitätsstandards, Stress zum Sprintende und „fertig“ heißt für jeden etwas anderes.
In diesem Beitrag lesen Sie, wie Sie eine Definition of Done im Scrum so aufsetzen und nutzen, dass sie im Alltag trägt – inklusive konkreter Beispiele, Formulierungen und Schritt-für-Schritt-Vorgehen für Teams und Entscheider.
Was ist die Definition of Done im Scrum – kurz erklärt
Die Definition of Done im Scrum ist eine klare, gemeinsam vereinbarte Liste von Qualitätskriterien, die erfüllt sein müssen, damit ein Product Backlog Item oder Increment als „fertig“ gilt.
Sie beantwortet eine einfache Frage:
„Woran erkennen wir, dass diese Arbeit wirklich abgeschlossen und potenziell lieferbar ist?“
Wichtig dabei:
- Sie gilt für alle Items (Stories, Tasks, Bugs), nicht nur für einzelne Fälle.
- Sie fokussiert auf Qualität und Fertigstellungsgrad, nicht auf Aufwand.
- Sie ist transparent, bekannt und für das ganze Scrum Team verbindlich.
Warum die Definition of Done entscheidend ist
Ohne robuste Definition of Done zahlen Teams und Organisationen einen hohen Preis – oft unbemerkt.
Typische Symptome:
- „Fertig“ heißt: Code ist geschrieben – aber nicht getestet.
- Anforderungen wechseln mitten im Sprint, „fertig“ wird nach hinten geschoben.
- Stakeholder verstehen nicht, warum Features nicht auslieferbar sind.
- Technische Schulden wachsen still im Hintergrund.
- Burnout-Gefahr im Team steigt, weil zum Sprintende „gerettet“ werden muss.
Eine gute Definition of Done wirkt wie ein Qualitätsfilter:
- Gleiches Verständnis von „fertig“ in Team, Management und Fachbereich.
- Weniger Diskussionen am Sprintende: Status ist objektiv überprüfbar.
- Bessere Planbarkeit: Velocity basiert auf echter Fertigstellung.
- Weniger Nacharbeiten: Fehler und Lücken fallen früher auf.
- Höhere Produktqualität: Jede Iteration erhöht verlässlich den Produktwert.
Für Entscheider bedeutet das: Sie bekommen eine realistischere Sicht auf Fortschritt und Risiken, statt geschönter Statusmeldungen.
Abgrenzung: Definition of Done vs. Akzeptanzkriterien vs. Arbeitsanweisungen
In der Praxis verschwimmen Begriffe schnell. Klare Trennung hilft Missverständnisse zu vermeiden.
Definition of Done
- Gilt generell für alle Product Backlog Items / Increments.
- Fokussiert auf Qualität und Fertigstellungsgrad.
- Beispiele:
- „Alle automatisierten Tests laufen fehlerfrei.“
- „Code ist im Main-Branch integriert.“
- „Dokumentation für Anwender ist aktualisiert.“
Akzeptanzkriterien (Acceptance Criteria)
- Gelten individuell pro User Story / Item.
- Beschreiben, wann diese eine Anforderung fachlich erfüllt ist.
- Beispiele:
- „Kunde kann seine Lieferadresse im Checkout ändern.“
- „Fehlermeldung erscheint, wenn Pflichtfelder leer sind.“
Arbeitsanweisungen / How-to
- Beschreiben Vorgehensweisen, Tools, Templates.
- Helfen, die DoD-Kriterien praktisch umzusetzen.
- Beispiele:
- „Für neue Endpunkte ist ein API-Contract im Wiki anzulegen.“
- „Code-Reviews erfolgen mindestens durch eine zweite Person.“
Merksatz:
Akzeptanzkriterien sagen: „Macht das Richtige.“
Definition of Done sagt: „Macht es richtig.“
Typische Fehler und Missverständnisse rund um die Definition of Done
Viele Scrum-Implementierungen scheitern nicht an der Theorie, sondern an Details im Alltag. Häufige Probleme:
- DoD nur als Poster an der Wand
Sie wird einmal in einem Workshop erstellt und dann ignoriert.
Folge: Sie hat keinen Einfluss mehr auf Verhalten, Planung oder Qualität. - Zu vage oder allgemein formuliert
Sätze wie „Qualität ist sichergestellt“ oder „Code ist getestet“ sind nutzlos.
Es fehlt die klare, überprüfbare Messbarkeit. - Nicht für alle sichtbar und bekannt
Management, Product Owner und Stakeholder wissen oft gar nicht, was „fertig“ im Team bedeutet.
Ergebnis: Erwartungs- und Kommunikationsprobleme. - Überfrachtete Definition of Done
Alles, was wünschenswert wäre, landet in der DoD.
Das Team kann sie im Sprint realistisch nicht einhalten, sie wird „optional“. - DoD wird von außen verordnet
Vorgaben aus der Organisation, ohne das Team einzubeziehen.
Konsequenz: geringe Akzeptanz, „Pflichtübung“, kreativer Widerstand. - Keine Anpassung an Reife und Kontext
Ein Senior-Team mit DevOps-Pipeline braucht eine andere DoD als ein frisch formiertes Team in reguliertem Umfeld.
Wenn sich Fähigkeiten und Rahmenbedingungen entwickeln, muss die DoD mitwachsen.
Konkrete Bestandteile einer starken Definition of Done
Eine nutzbare DoD ist konkret, praktisch und überprüfbar. Folgende Bereiche sollten Sie typischerweise abdecken:
1. Qualität & Testing
- Unit-Tests für neue oder geänderte Funktionen vorhanden
- Relevante Integrationstests aktualisiert
- Akzeptanztests für kritische Pfade durchgeführt
- Keine bekannten Blocker-Bugs im Umfang des Items
- Smoke-Tests für das Increment erfolgreich
2. Code & Architektur
- Code-Review durch mindestens eine weitere Person
- Coding-Guidelines eingehalten
- Keine bewusste Einführung neuer „TODO“-Schulden ohne Dokumentation und Priorisierung
- Sicherheitsrelevante Aspekte berücksichtigt (z. B. Input-Validierung)
3. Integration & Deployment
- Code in den Hauptbranch integriert
- Build läuft automatisiert und fehlerfrei
- Relevante Konfigurationen angepasst
- Feature ist in der vorgesehenen Umgebung deploybar oder deployed
4. Dokumentation
- Änderungsdokumentation (Changelog, Release Notes) aktualisiert
- Nutzerrelevante Dokumentation angepasst (Help, FAQ, Handbücher)
- Technische Dokumentation ergänzt, falls erforderlich (API, Schnittstellen, Datenmodelle)
5. Fachliche Abnahme
- Product Owner hat das Ergebnis gesehen und bewertet
- Offene Fragen oder Einschränkungen sind dokumentiert und im Backlog erfasst
Nicht jedes Team braucht jeden Punkt. Wichtig ist: Jeder Punkt sollte überprüfbar sein.
Fragen Sie sich bei jedem Kriterium:
„Könnten zwei Personen unabhängig voneinander feststellen, ob dieses Kriterium erfüllt ist?“
Wenn nein, ist es zu unklar formuliert.
Beispiel: Definition of Done für ein Software-Produktteam
Ein möglicher, praxistauglicher DoD-Entwurf für ein Web-Entwicklungsteam könnte so aussehen:
Ein Item gilt als „Done“, wenn:
- Fachliche Umsetzung
- Alle Akzeptanzkriterien der User Story sind erfüllt.
- Wesentliche Randfälle sind berücksichtigt.
- Qualität & Tests
- Unit-Tests wurden geschrieben und laufen fehlerfrei.
- Relevante Integrationstests sind aktualisiert.
- Bei UI-Änderungen sind die wichtigsten Browser / Geräte geprüft.
- Es bestehen keine bekannten Blocker oder kritischen Bugs im Umfang der Änderung.
- Code & Review
- Code wurde von mindestens einer zweiten Person reviewed.
- Coding-Standards des Teams wurden eingehalten.
- Potentielle Performance- oder Sicherheitsrisiken wurden adressiert oder explizit dokumentiert.
- Integration & Deploybarkeit
- Code ist im Main-Branch integriert.
- CI-Pipeline ist grün (Build, Tests).
- Konfigurationen / Feature-Toggles sind angepasst.
- Das Increment ist prinzipiell produktiv deploybar.
- Dokumentation & Kommunikation
- Relevante Änderungen sind im Changelog vermerkt.
- Anwenderdokumentation ist aktualisiert, falls nötig.
- Technische Dokumentation (z. B. API) ist angepasst.
Wichtig: Das ist ein Startpunkt, kein Dogma. Jedes Team muss seine DoD auf den eigenen Kontext zuschneiden.
Wie man eine Definition of Done im Scrum-Team einführt – Schritt für Schritt
Viele Teams wissen, dass sie eine DoD brauchen, scheitern aber an der Umsetzung. So gehen Sie pragmatisch vor:
Ausgangslage klären
- Aktuelle Probleme sammeln:
- Wo gibt es heute Diskussionen über „fertig“?
- Wo entstehen unnötige Nacharbeiten?
- Wo fühlen sich Stakeholder überrascht oder enttäuscht?
- Nicht nur die Entwickler fragen, sondern auch:
- Product Owner
- Stakeholder / Fachbereich
- ggf. Qualitätssicherung, Betrieb/IT
Workshop vorbereiten
- Ziel klar machen: „Gemeinsames Verständnis von ‚fertig‘ schaffen.“
- Teilnehmer:
- gesamtes Scrum Team (Developers, Product Owner, Scrum Master)
- optional: Vertreter aus QA, Betrieb, Architektur
- Material bereitstellen:
- Beispiele aus der Vergangenheit (gelungene und problematische Sprints)
- Aktuelle Standards / Richtlinien (Security, Compliance, Architektur)
DoD-Entwurf im Team erarbeiten
Vorgehen im Workshop:
- Brainstorming:
„Wenn wir stolz sagen wollen: Das ist wirklich fertig – was muss erfüllt sein?“
Alle Punkte ungefiltert sammeln. - Clustern nach Bereichen:
- Qualität/Tests
- Code/Architektur
- Integration/Deployment
- Dokumentation/Abnahme
- Priorisieren:
- Welche Punkte sind zwingend, damit wir verantwortungsvoll liefern?
- Was sind Wunschpunkte, die wir später ergänzen können?
- Schärfen:
- Vage Formulierungen konkret machen.
- Kriterien messbar und überprüfbar formulieren.
Schritt 4: DoD sichtbar machen
- DoD dort platzieren, wo das Team arbeitet:
- Taskboard / digitales Board
- Team-Wiki
- Definition of Done-Karte im Backlog-Tool
- Sicherstellen, dass auch Management und Stakeholder Zugang haben.
- Kurzfassung bereitstellen, z. B. für Onboarding neuer Teammitglieder.
Schritt 5: DoD im Arbeitsalltag verankern
- In jedem Sprint Planning:
- Sicherstellen, dass das Team die DoD bei der Schätzung mitdenkt.
- Im Daily Scrum:
- Fragen wie „Was fehlt noch, damit das Item DoD-konform fertig ist?“ einbauen.
- Im Sprint Review:
- Transparenz schaffen, wenn Items die DoD nicht erfüllen (und daher nicht als „Done“ gelten).
- In der Retrospektive:
- Prüfen, ob die DoD funktioniert, überladen ist oder Lücken zeigt.
Wie die Definition of Done in den Scrum-Events genutzt wird
Die Definition of Done sollte kein statisches Dokument sein, sondern Teil der täglichen Arbeit.
Produkt Backlog & Refinement
- Product Owner und Entwickler klären früh:
- Ist das geplante Item grundsätzlich unter Einhaltung der DoD im Sprint umsetzbar?
- Erhöht die DoD sichtbare Komplexität (z. B. durch zusätzliche Tests, Dokumentation)?
Sprint Planning
- Das Team berücksichtigt Aufwand für:
- Tests gemäß DoD
- notwendige Dokumentation
- Integration und Abhängigkeiten
- Wenn klar ist, dass die DoD für ein Item nicht eingehalten werden kann:
- Item nicht in den Sprint ziehen oder Umfang anpassen.
- Alternativ: gemeinsam explizit Risiken und Abweichungen besprechen.
Daily Scrum
- Fokuswechsel von „Tasks abhaken“ zu „DoD erfüllen“:
- „Was fehlt diesem Item noch, um unsere Definition of Done zu erreichen?“
- „Hindert uns etwas, bestimmte DoD-Punkte einzuhalten?“
Sprint Review
- Nur Items präsentieren, die die DoD erfüllen.
- Ausnahmen (bewusst nicht erfüllte DoD-Punkte) transparent ansprechen.
- Management und Stakeholder verstehen damit, was „fertig“ im Team bedeutet.
Sprint Retrospektive
- DoD regelmäßig reflektieren:
- „Welche DoD-Punkte konnten wir stabil einhalten?“
- „Wo hatten wir immer wieder Probleme?“
- „Welche Qualitätsprobleme sind aufgetreten, obwohl die DoD erfüllt war?“
- DoD anzupassen ist ein Zeichen von Lernen, nicht von Scheitern.
Umgang mit „Nicht-DoD-konformer“ Arbeit
In der Realität wird es Situationen geben, in denen Teile der DoD nicht erfüllt werden können. Entscheidend ist der bewusste Umgang damit.
Mögliche Szenarien:
- Kritischer Produktions-Fehler, schnelles Fix notwendig
- Team entscheidet transparent, welche DoD-Punkte zuerst entfallen (z. B. ausführliche Dokumentation).
- Nacharbeiten werden als eigenes Item im Backlog erfasst und priorisiert.
- Abhängigkeiten verhindern bestimmte Tests oder Deployments
- DoD-Abweichung im Review offenlegen.
- Klar dokumentieren, welche Risiken bestehen.
- Maßnahmen für Folgesprints festlegen.
- Organisation erwartet „Schein-Fertigstellung“
- Hier braucht es Führung.
- Als Entscheider sollten Sie DoD-Verletzungen nicht einfordern, um schnelle Scheinfortschritte zu sehen.
- Besser: Transparenz akzeptieren und gemeinsam Hindernisse adressieren.
Wichtig: Wird die DoD systematisch ignoriert, verliert sie jede Wirkung. Dann ist sie de facto abgeschafft – auch wenn sie formal noch existiert.
Skalierung: Definition of Done auf Team- und Organisationsebene
In größeren Organisationen mit mehreren Scrum-Teams rund um ein Produkt stellt sich eine weitere Frage: Wie einheitlich muss die Definition of Done sein?
Pragmatischer Ansatz:
- Organisationsebene / Produktlinie
- Verbindliche Mindeststandards definieren, z. B.:
- Einhaltung regulatorischer Vorgaben
- Sicherheitsanforderungen
- Compliance / Datenschutz
- Diese gelten für alle Teams als Baseline-DoD.
- Verbindliche Mindeststandards definieren, z. B.:
- Team-Ebene
- Jedes Team ergänzt die Baseline um:
- Technologie-spezifische Aspekte
- Team-spezifische Praktiken (z. B. Pair Programming, Architektur-Guidelines)
- Jedes Team ergänzt die Baseline um:
So entsteht ein zweistufiges Modell:
- Globale DoD: minimaler Qualitätsstandard für das gesamte Produkt.
- Team-DoD: Erweiterung, die zur Realität und Reife des Teams passt.
Das reduziert Wildwuchs und sorgt trotzdem für genügend Flexibilität.
Reifegrad: Die Definition of Done im Laufe der Zeit weiterentwickeln
Eine DoD ist kein einmaliger Akt, sondern ein Entwicklungsprozess. Typische Entwicklung:
- Einstiegsphase
- Fokus auf grundlegende Aspekte:
- „Code reviewed“
- „Basis-Tests vorhanden“
- „Deploybar“
- Fokus auf grundlegende Aspekte:
- Stabilisierungsphase
- Ausbau automatisierter Tests
- Stärkere Einbindung von Security und Performance
- Bessere Dokumentationsstandards
- Hohe Reife
- Vollständig automatisierte Build-, Test- und Deployment-Pipeline
- Metrik-basierte Qualitätskriterien (z. B. Code-Coverage-Grenzen nicht dogmatisch, sondern reflektiert)
- Kontinuierliche Überprüfung der DoD anhand realer Produktionsvorfälle
Ein hilfreicher Ansatz:
In jeder zweiten oder dritten Retrospektive gezielt fragen:
- „Welchen einen DoD-Punkt wollen wir im nächsten Sprint verbessern oder ergänzen?“
- „Welchen Punkt können wir streichen, weil er keine Wirkung zeigt?“
So wächst die DoD Schritt für Schritt – passend zur Entwicklung des Teams.
Rolle von Product Owner, Scrum Master und Management
Product Owner
- Achtet darauf, dass Items nur als „Done“ gelten, wenn die DoD erfüllt ist.
- Unterstützt bei der Priorisierung von Arbeit, die zur DoD-Einhaltung nötig ist (Tests, Refactoring etc.).
- Kommuniziert Stakeholdern klar, was „fertig“ bedeutet – und was nicht.
Scrum Master
- Schafft Bewusstsein für den Wert der DoD.
- Moderiert Workshops zur Erstellung und Weiterentwicklung.
- Achtet darauf, dass die DoD in Ereignissen wie Daily, Review und Retro genutzt wird.
- Hilft dem Team, Hindernisse bei der Einhaltung der DoD sichtbar zu machen und zu adressieren.
Management und Führungskräfte
- Akzeptieren, dass Transparenz manchmal „unangenehme Wahrheiten“ zeigt.
- Fördern statt bestrafen, wenn Teams ehrlich mit der DoD umgehen.
- Stellen Rahmenbedingungen bereit:
- Zeit und Ressourcen für Tests, Automatisierung, Qualitätssicherung.
- Unterstützung beim Abbau technischer Schulden.
Wenn Führungsebene und Teams hier an einem Strang ziehen, wird die Definition of Done zu einem wirksamen Instrument für nachhaltige Lieferfähigkeit.
Fazit: Definition of Done im Scrum als Hebel für echte Qualität
Eine gute Definition of Done ist mehr als eine Liste schöner Vorsätze. Sie ist:
- ein gemeinsamer Qualitätsvertrag im Scrum Team,
- ein Transparenzinstrument für Stakeholder,
- ein Schutzmechanismus gegen technische Schulden,
- ein Hebel für verlässliche Lieferfähigkeit.
Wenn „fertig“ in Ihrer Organisation heute noch Verhandlungssache ist, lohnt es sich, hier anzusetzen. Nutzen Sie die nächste Retrospektive oder einen fokussierten Workshop, um Ihre Definition of Done zu schärfen – oder überhaupt erst wirksam zu machen.
Wenn Sie Unterstützung bei der Einführung oder Weiterentwicklung von Scrum, inklusive Definition of Done, in komplexen Umgebungen suchen, kann eine externe Perspektive helfen. Die Beraterinnen und Berater von PURE Consultant begleiten Teams und Entscheider genau in diesen Fragestellungen – von ersten Pilotprojekten bis zur skalierenden agilen Organisation.