Die Definition of Done (DoD) ist die formale Beschreibung des Zustands eines Inkrements, wenn es alle geforderten Qualitätskriterien erfüllt. Sobald ein Product Backlog Item die DoD erfüllt, entsteht ein Inkrement – gebrauchsfertig und potenziell lieferbar. Die DoD schafft Transparenz darüber, was „fertig“ tatsächlich bedeutet und verhindert Missverständnisse zwischen Teams, Product Ownern und Stakeholdern.
Im Scrum Guide ist festgelegt: Wenn mehrere Scrum-Teams am selben Produkt arbeiten, müssen sie eine gemeinsame DoD definieren und einhalten. Zusätzliche Team-spezifische Verschärfungen sind erlaubt, ersetzen aber die gemeinsame Produkt-DoD nicht.
Arten von DoD – offiziell vs. Praxis
- Produkt-DoD (offiziell, Scrum Guide)
Die verbindliche Definition für das gesamte Produkt. Alle Teams, die an demselben Produkt arbeiten, müssen diese DoD einhalten.
Beispiel: „Alle Features integriert, Regressionstests grün, Betriebsdokumentation aktualisiert.“
- Team-DoD (praktische Ergänzung)
Teams können strengere Regeln ergänzen, die über die produktweite DoD hinausgehen.
Beispiel: „Code Coverage ≥ 80 %, alle Pull Requests reviewed.“
- Organisationale DoD (praktische Ergänzung)
Von der Organisation vorgegebene Baselines (z. B. Architektur, Security, Compliance), die alle Produkte erfüllen müssen.
Beispiel: „Security-Scan ohne kritische Findings, Datenschutz-Check durchgeführt.“
- Release-/Deployment-DoD (praktische Ergänzung)
Definiert, wann ein Inkrement tatsächlich in Produktion überführt werden kann. Ergänzt die Produkt-DoD um Betriebs- und Deployment-Aspekte.
Beispiel: „Deployment automatisiert über CI/CD, Monitoring-Alerts getestet, Release Notes erstellt.“
Wichtig: Offiziell kennt Scrum nur die produktweite DoD. Die weiteren Ebenen sind praktische Erweiterungen, die in komplexen Organisationen sinnvoll sind.
Praxisbezug
- Transparenz & Qualität: DoD macht sichtbar, was unverhandelbar erfüllt sein muss.
- Integration: Gemeinsame DoD über Teams hinweg verhindert „Integration Hell“.
- Planbarkeit: Stakeholder wissen, dass jedes Inkrement die gleiche Qualitätsbasis hat.
- Automatisierung: Moderne Organisationen bilden die DoD-Kriterien in CI/CD-Pipelines ab, um Konsistenz sicherzustellen.
- Regulierung: In Branchen wie Automotive, MedTech oder Finance ist die DoD auch Nachweis gegenüber Auditoren.
Abgrenzung zu verwandten Begriffen
- Acceptance Criteria: Item-spezifische Kriterien („bauen wir das Richtige?“).
- DoD: Produktweite Qualitätsbasis für das Inkrement („bauen wir es richtig?“).
- DoR (Definition of Ready): Nicht offiziell im Scrum Guide, aber verbreitet – beschreibt, wann ein Item startklar für die Umsetzung ist.
Praktische Beispiele (ausführlich)
Cloud-SaaS (Team-DoD):
- Code reviewed, Unit-Tests ≥ 80 %, API-Doku aktualisiert.
- Vorteil: Konsistenz innerhalb des Teams, weniger Nacharbeit, stabilere Releases.
Automotive (Produkt-DoD):
- Alle Softwarestände integriert, Hardware-in-the-Loop bestanden, Safety-Case aktualisiert.
- Vorteil: Alle Teams liefern kompatible Softwarestände, Integration wird planbar.
MedTech (Organisationale DoD):
- Traceability zwischen Anforderungen, Tests und Risiken vorhanden, Validierungsprotokolle abgeschlossen.
- Vorteil: Audit-Sicherheit, regulatorische Compliance nach GxP/ISO 13485.
Finanzsektor (Release-/Deployment-DoD):
- Deployment automatisiert, Monitoring aktiv, Runbooks für Incidents vorhanden.
- Vorteil: Produktionssysteme stabil, Releases vorhersehbar und prüfbar.
Data/ML-Produkte (Team + Produkt-DoD):
- Model reproducibility gesichert, Data-Quality-Gates erfüllt, Drift-Monitoring aktiv.
- Vorteil: Vertrauen in Machine-Learning-Produkte, Nachvollziehbarkeit für Auditoren.
Umsetzung in der Praxis
- Workshop: DoD gemeinsam definieren, Organisation-Policies berücksichtigen.
- Automatisieren: DoD-Kriterien so weit wie möglich in CI/CD abbilden (Tests, Security-Scans, Compliance).
- Iterativ verschärfen: DoD sollte mit der Reife des Teams/Produkts wachsen (z. B. höhere Testabdeckung, tiefere Security-Prüfungen).
- Transparenz schaffen: Im Sprint Review und mit Metriken spiegeln, ob Items die DoD erfüllen.
Anti-Patterns
- „Done = Code fertig“ – Qualität, Tests und Betrieb werden ignoriert.
- Unterschiedliche DoDs bei Teams am selben Produkt – explizit im Scrum Guide verboten.
- Papier-DoD ohne Automatisierung – niemand lebt sie.
- Verwechslung mit Acceptance Criteria – führt zu Schein-„Fertig“.
CALADE-Sichtweise
Wir betrachten die DoD als mehrschichtiges Qualitätsmodell:
- Produktweite DoD als verbindlicher Standard.
- Team-spezifische Erweiterungen für Details.
- Organisationale Baselines für Compliance und Sicherheit.
- Release-/Deployment-DoD für den Brückenschlag zu Betrieb und Markt.
So wird die DoD von einer Checkliste zu einem lebendigen Steuerungsinstrument für Qualität, Vertrauen und Business Value.
← zurück zur Übersicht