In wachsenden Teams ist „fertig" meistens das teuerste Wort. Eine Aufgabe gilt als erledigt, und im nächsten Sprint kommt sie als Nacharbeit zurück. Das frustriert das Team, kostet Tempo und untergräbt das Vertrauen zwischen Stakeholdern und Umsetzung.
Genau hier setzt die Definition of Done (DoD) an. Sie ist die gemeinsame Zusage, was „fertig" für ein Team praktisch bedeutet, überprüfbar, verbindlich und unabhängig vom einzelnen Vorhaben. Im aktuellen Scrum Guide (2020) ist sie das Commitment zum Increment: ohne DoD gibt es kein gültiges Ergebnis.
Warum unfertige Ergebnisse so teuer sind
In KMU sehen wir typische Muster:
- Ergebnisse sind „im Prinzip fertig", aber nicht freigegeben.
- Tests, Dokumentation oder Übergabe werden in den nächsten Sprint geschoben.
- Stakeholder erwarten Releaserfähiges, das Team meint Beta.
- Die Geschäftsführung muss klären, was eigentlich gilt, und wird zum Engpass.
Eine DoD löst diesen Konflikt durch Klarheit vor Beginn der Arbeit. Sie verschiebt den Aushandlungsmoment dorthin, wo er hingehört: vor den Sprint, nicht ins Review.
Definition: Was die DoD ist, und was nicht
Die DoD ist eine gemeinsam vereinbarte Liste von Qualitätskriterien, die für jedes Increment gelten, unabhängig vom konkreten Inhalt. Sie ist nicht:
- eine Checkliste pro Story (das sind Akzeptanzkriterien),
- ein Status-Bericht („zu 80% fertig"),
- ein einseitiges Versprechen des Teams an die Stakeholder.
Sie ist eine Vereinbarung des gesamten Scrum-Teams, Product Owner, Developers und Scrum Master gemeinsam. Erst wenn alle Punkte der DoD erfüllt sind, gilt ein Backlog-Item als „done".
DoD vs. Acceptance Criteria vs. Definition of Ready
Drei Begriffe, die häufig vermischt werden, mit großer Wirkung auf den Alltag:
| Konzept | Gilt für | Frage |
|---|---|---|
| Definition of Ready (DoR) | jedes Backlog-Item *vor* dem Sprint | Ist diese Story bereit, bearbeitet zu werden? |
| Acceptance Criteria | eine *einzelne* Story | Erfüllt das Ergebnis genau diese Anforderung? |
| Definition of Done (DoD) | das Increment als Ganzes | Hat das Team Qualität geliefert, die im Markt bestehen kann? |
Praktisches Bild: Die DoR ist der Eingangs-Check, die Acceptance Criteria sind die fachliche Prüfung, die DoD ist der Qualitäts-Gatekeeper. Erst die Kombination macht Lieferung verlässlich.
Drei Ebenen: Feature, Sprint, Release
Eine DoD muss nicht eindimensional sein. In wachsenden Organisationen lohnt sich eine Staffelung:
- Feature-Ebene: Was muss erfüllt sein, damit eine einzelne Funktion oder ein einzelnes Ergebnis nutzbar ist? (z.B. Code-Review, Tests, Dokumentation aktualisiert)
- Sprint-Ebene: Was muss erfüllt sein, damit das gesamte Sprint-Ergebnis ein potenzielles Increment ist? (z.B. Integration in den Hauptzweig, kein offener kritischer Bug)
- Release-Ebene: Was muss erfüllt sein, damit das Increment veröffentlicht werden kann? (z.B. Sicherheits-Check, Performance-Check, Stakeholder-Freigabe, Release-Notes)
In kleinen Teams reicht oft die Feature-Ebene. Sobald Sie regelmäßig releasen oder mehrere Teams an einem Produkt arbeiten, lohnen sich alle drei Ebenen.
Beispiele aus vier Kontexten
Die DoD ist kein reines Software-Konzept. Sie funktioniert überall dort, wo Ergebnisse übergeben und freigegeben werden.
Software-Entwicklung
- Code wurde von mindestens einer weiteren Person reviewt.
- Unit- und Integrationstests sind geschrieben und grün.
- Die Funktion wurde in einer Staging-Umgebung verifiziert.
- Benutzerdokumentation ist aktualisiert.
- Code ist im Hauptzweig integriert.
Engineering- oder Beratungs-KMU (Service-Lieferung)
- Ergebnisartefakt liegt im vereinbarten Format vor (Bericht, Konzept, Konstruktionszeichnung).
- Fachliche Vier-Augen-Prüfung ist erfolgt und dokumentiert.
- Annahmen, Quellen und offene Punkte sind erkennbar gekennzeichnet.
- Übergabe an die nächste Stufe (Kunde, Vertrieb, nächstes Gewerk) ist abgestimmt.
Marketing- und Content-Arbeit
- Inhalt erfüllt die definierten Qualitätskriterien (Tonalität, Faktencheck, Quellen).
- Bild- und Mediaformate liegen in den vereinbarten Größen vor.
- SEO-Mindestanforderungen sind eingehalten (Title, Meta, H1, interne Links).
- Veröffentlichung im richtigen Kanal ist eingeplant oder durchgeführt.
- Tracking funktioniert.
Produktherstellung
- Stückprüfung ist durchgeführt und dokumentiert.
- Verpackung und Etikettierung entsprechen Vorgabe.
- Begleitdokumente (Datenblatt, Konformitätserklärung) sind erstellt.
- Sicherheits- und Normprüfungen sind bestanden.
Es geht nicht darum, die längste Liste zu haben. Eine DoD wirkt, wenn sie ehrlich gelebt wird, fünf harte Kriterien schlagen zwanzig formale.
Wer erstellt die DoD?
Das gesamte Scrum-Team beschließt die DoD gemeinsam. In der Praxis hat sich ein kurzer Workshop bewährt:
- Mindeststandard sammeln: Was ist nicht verhandelbar (z.B. Compliance, Sicherheit, Vier-Augen-Prinzip)?
- Praxisrealität prüfen: Was leisten wir tatsächlich heute? Wo besteht Lücke zur Wunsch-DoD?
- Erste DoD vereinbaren: Auf Minimalniveau starten, nicht alle Kriterien gleichzeitig durchsetzen.
- Sichtbar machen: DoD im Backlog-Tool, am Board, im Wiki, überall, wo Übergaben stattfinden.
Bei größeren oder regulierten Organisationen kann es sinnvoll sein, eine organisationsweite DoD vorzugeben (z.B. Compliance-Mindeststandards). Teams dürfen sie dann verschärfen, aber nicht aufweichen.
Drei Anti-Pattern und Korrekturen
Anti-Pattern 1: DoD als formale Pflichtübung.
Die Liste existiert, aber niemand prüft sie im Review. Stories gelten als „done", obwohl Kriterien offen sind. Korrektur: DoD im Review aktiv anwenden, pro Item gegen die Liste prüfen. Nicht erfüllt = nicht done.
Anti-Pattern 2: Zu lange DoD.
Die Liste umfasst 25 Punkte, niemand kann sie auswendig. In der Praxis wird sie ignoriert. Korrektur: Auf 5–8 wirklich harte Kriterien reduzieren. Lieber drei lebendige Kriterien als zwanzig auf Papier.
Anti-Pattern 3: DoD wird stillschweigend verschoben.
„Die Tests reichen wir nach" wird zur Routine. Technische Schuld wächst, aber niemand spricht darüber. Korrektur: Verschobene DoD-Punkte als Backlog-Item führen, transparent, priorisierbar, planbar. Keine stillen Ausnahmen.
30-Tage-Einführung ohne Bürokratie
Woche 1
- Workshop mit dem Team: erste DoD-Version auf 5–8 Punkte einigen.
- Punkte sichtbar machen (Board, Wiki).
Woche 2
- Erstes Review unter neuer DoD durchführen.
- Pro Item gegen die Liste prüfen, auch wenn das ungewohnt ist.
Woche 3
- Lücken auswerten: Welche Kriterien werden regelmäßig verfehlt? Liegt es an der DoD oder am Vorgehen?
- Falls nötig: ein Kriterium schärfen oder vereinfachen.
Woche 4
- Erste Retrospektive zur DoD: Was hat geholfen? Was ist Theater?
- Cadence festlegen: DoD wird quartalsweise gegengeprüft.
Kontinuierliche Nachschärfung
Die DoD ist kein statisches Dokument. In der Sprint Retrospective wird sie regelmäßig angeschaut:
- Ist sie noch passend zum aktuellen Reifegrad?
- Welche neuen Kriterien sind in der Praxis dazugekommen (Compliance-Anforderung, Performance-Erwartung)?
- Welche alten Kriterien sind redundant geworden?
Faustregel: Wenn die DoD ein Jahr lang unverändert geblieben ist, ist sie wahrscheinlich nicht mehr ehrlich.
The Increment and Definition of Done, Scrum Foundations eLearning Series
Dieses Video wird von YouTube bereitgestellt. Beim Laden werden Daten an deren Server übertragen.
Häufige Fragen zur Definition of Done
Wer entscheidet bei Streit über die DoD?
Das Team, gemeinsam. Der Scrum Master moderiert, aber nicht der PO oder die Führung entscheiden allein. DoD ist ein Team-Commitment.
Was passiert, wenn die DoD nicht erfüllt ist?
Das Item ist nicht „done”. Es bleibt im Sprint Backlog (wenn der Sprint noch läuft) oder geht zurück ins Product Backlog. Es darf nicht im Review präsentiert werden.
Wie unterscheidet sich die DoD von Acceptance Criteria?
Acceptance Criteria gelten pro Story (was muss diese Funktion können?). Die DoD gilt für jedes Increment (welche Qualität gilt unabhängig vom Inhalt?).
Brauche ich eine eigene DoD pro Team?
Wenn mehrere Teams an einem Produkt arbeiten, braucht es eine gemeinsame Mindest-DoD, sonst sind Increments nicht integrierbar. Teams dürfen die DoD verschärfen, nicht aufweichen.
Funktioniert eine DoD auch außerhalb von Software?
Ja. In Engineering-Beratungen, Marketing-Teams oder Service-Lieferung wirkt sie genauso, überall dort, wo Ergebnisse übergeben werden und Qualität nicht offensichtlich ist.
Strategiegespräch
Wenn „fertig” bei Ihnen unklar ist
Wenn Übergaben in Ihrem Team regelmäßig nachgebessert werden müssen, fehlt meist eine gelebte Definition of Done. Eine kurze Diagnose zeigt, an welcher Stelle der Übergang gerade Reibung erzeugt, bevor mehr Prozesse hinzukommen, die das Symptom überdecken.
→ Strategiegespräch vereinbarenWeiterführend
Daily Scrum richtig nutzen: kurz, klar, wirksam
Daily Scrum ohne Statusmeeting-Falle: So richtet das Team den Tag aufs Sprint-Ziel aus, deckt Blocker früh auf und passt den Plan für die nächsten 24 Stunden an.
Was ist Scrum? Der kompakte Leitfaden für KMU
Scrum einfach erklärt: Rollen, Events, Artefakte und Werte. So setzen Sie das Framework sinnvoll in wachsenden Teams ein, mit 30-Tage-Einstieg.
User Stories in Scrum: Klar priorisieren, besser liefern
Wie User Stories in Scrum zu klaren Prioritäten und besseren Ergebnissen führen. Mit Template, INVEST, Akzeptanzkriterien und Beispielen für Teams in KMU.
