Definition of Done: Wann bin ich wirklich fertig?

Die Definition of Done (DoD) legt fest, wann ein Product Backlog Item als fertig gilt. Die Definition of Ready (DoR) beschreibt, ob ein Product Backlog Item so vorbereitet ist, dass das Team mit der Umsetzung starten kann.

Wann Definition of Ready und Definition of Done zum Einsatz kommen

Beide verfolgen das gleiche Ziel:

  • höhere Qualität
  • klare Erwartungen
  • weniger Missverständnisse
  • ein besseres Produkt-Ergebnis

Ein guter Ausgangspunkt zur Definition der DoR ist INVEST

Interne und externe Anforderungen

Die Definition of Done umfasst sowohl organisatorische Vorgaben als auch teaminterne Qualitätskriterien.

Beispiele für organisatorische Anforderungen:

  • Verpflichtende Code Reviews
  • Einhalten von Compliance- oder Sicherheitsrichtlinien
  • Erforderliche Dokumentationsstandards

Beispiele für teaminterne Anforderungen:

  • Merge in den Master-Branch
  • Automatisierte Tests wurden ausgeführt
  • UI/UX-Abnahme erfolgt

Diese Anforderungen gelten global für alle Product Backlog Items.

Definition of Done: eine Team-Angelegenheit

Im Verlauf des Sprints werden alle Punkte des DoD abgearbeitet. Die Einhaltung liegt vollständig bei den Developer*innen.

Eine User Story gilt erst dann als done, wenn alle Kriterien erfüllt sind. Nicht nur die funktionalen.

Mehrere Ebenen der Definition of Done

In vielen Teams und Organisationen existiert die DoD auf mehreren Ebenen. Diese Struktur bringt Klarheit, Transparenz und ein gemeinsames Qualitätsverständnis.

Level 1: Product-Backlog-Item-Ebene (PBI)

  • Akzeptanzkriterien erfüllt
  • Hinreichende Dokumentation erstellt
  • 4-Augen-Prinzip berücksichtigt
  • Unit Tests erfolgreich
  • UI-Abnahme erfolgt

Level 2: Sprint-Ebene

  • Sprint-Branch geschlossen und in Master gemergt
  • Follow-Up-Tickets erstellt
  • Offene Tickets besprochen und Entscheidung getroffen
  • Regressionstests durchgeführt
  • Keine offenen Blocker

Level 3: Release-Ebene

  • Feature integriert und End-to-End getestet
  • Meta-Daten auf das Release angepasst
  • Release Notes erstellt und veröffentlicht
  • Stakeholder über das Release informiert
  • Monitoring/Telemetrie vorbereitet
💡 Hinweis: Mehrstufige DoD-Modelle sind besonders hilfreich in skalierten Umgebungen wie CALM, SAFe, LeSS oder Nexus.

Newsletter

Praxiswissen direkt ins Postfach

Neue Artikel, Leadership-Impulse und kostenlose Downloads – kompakt und direkt umsetzbar.

Jetzt anmelden →

DSGVO-konform. Kein Spam. Jederzeit abbestellbar.

Scrum Definition of Ready: Hat das Team die Story verstanden?

Die Definition of Ready (DoR) stellt sicher, dass ein Product Backlog Item umsetzbar ist. Sie ist keine harte Eintrittsbarriere für das Sprint Planning. Teams können sie auch im Planning vervollständigen.

Scrum Definition of Ready Beispiel

Der Product Owner ist verantwortlich für die Erfüllung der DoR.

  • Die User Story ist formal beschrieben
  • Acceptance Criteria wurden definiert
  • Der Umfang der User Story ist klein genug für einen Sprint
  • Die Story wurde geschätzt
  • Abhängigkeiten wurden geklärt
  • Fachliche Fragen des Teams wurden beantwortet

DoD vs. DoR: Die wichtigsten Unterschiede

Definition of Done (DoD) Definition of Ready (DoR)
Prüft, ob eine Story fertig ist Prüft, ob eine Story startbereit ist
Verantwortung der Developer*innen Verantwortung des Product Owners
Qualität der Umsetzung Qualität der Vorbereitung
Gilt während und am Ende des Sprints Gilt vor bzw. im Sprint Planning

Warum DoD und DoR essenziell sind

Vorteile der DoD

  • Einheitliche Qualitätsstandards
  • Weniger technische Schulden
  • Transparenz für Stakeholder
  • Bessere Vorhersagbarkeit

Vorteile der DoR

  • Klare Erwartungen vor dem Sprint
  • Weniger Rückfragen und Rework
  • Bessere Planbarkeit
  • Stabilere Velocity

Fazit

Eine gute Definition of Done und eine klare Definition of Ready sorgen für:

  • Mehr Transparenz
  • Weniger Missverständnisse
  • Höhere Qualität
  • Planbare Ergebnisse
  • Mehr Vertrauen in das Team

Besonders wirkungsvoll werden sie, wenn sie mehrstufig aufgebaut sind – z. B. auf PBI-, Sprint- und Release-Level.

Das könnte Dich auch interessieren:

Teilen:

War dieser Artikel hilfreich?

Häufige Fragen

Wozu braucht ein Team eine Definition of Done?
Eine Definition of Done sorgt dafür, dass alle im Team das gleiche Verständnis davon haben, wann ein Arbeitsergebnis wirklich fertig ist. Sie reduziert Missverständnisse, stärkt die Qualitätssicherung und hilft, Verzögerungen zu vermeiden, die durch nachträgliche Korrekturen entstehen.
Was gehört typischerweise in eine Definition of Done?
Typische Bestandteile sind:
  • fachliche Anforderungen erfüllt
  • Code getestet und dokumentiert
  • Qualitätskriterien eingehalten
  • Abnahme- oder Review-Prozess durchlaufen
  • Integration, Deployment oder andere technische Schritte abgeschlossen
Welche Punkte konkret enthalten sind, hängt vom Team und Produkt ab.
Wie unterscheidet sich die Definition of Done von Akzeptanzkriterien?
Akzeptanzkriterien gelten für eine einzelne User Story und beschreiben, was sie im Detail leisten muss. Die Definition of Done gilt für alle Aufgaben oder User Stories im Team und beschreibt den allgemeinen Qualitätsstandard, der immer erfüllt sein muss – unabhängig vom Inhalt der Story.

Kostenlose 10-Tage-Challenge

Selbstmanagement Sprint

Mehr Klarheit und Fokus in 10 Tagen – täglich 5–10 Minuten, sofort umsetzbar.

Jetzt kostenlos starten →