Definition of Ready auf einen Blick
- Was?
- Kriterien, die eine User Story vor dem Sprint erfüllen muss
- Ziel
- Vermeidung von unklaren Anforderungen im Sprint
- Prüfung
- Im Backlog Refinement und spätestens im Sprint Planning
- Hinweis
- Steht nicht im Scrum Guide — ist eine ergänzende Praxis
Welche Kriterien gehören in eine Definition of Ready?
Die konkreten Kriterien variieren je nach Team und Kontext. Ein guter Startpunkt:
- User Story ist formuliert — im „Als … möchte ich … damit"-Format mit klarer Nutzerperspektive
- Akzeptanzkriterien definiert — messbar und testbar
- Aufwand geschätzt — z.B. per Planning Poker
- Abhängigkeiten geklärt — externe Zulieferungen, API-Zugänge, Design-Assets
- Story ist klein genug — passt in einen Sprint (kein Epic)
Was ist der Unterschied zur Definition of Done?
Stell dir einen Tunnel vor: Die Definition of Ready ist das Eingangstor — sie prüft, ob eine Story bereit ist, bearbeitet zu werden. Die Definition of Done ist das Ausgangstor — sie prüft, ob die Arbeit tatsächlich fertig ist.
- DoR: Eingangsqualität → Ist die Anforderung klar genug?
- DoD: Ausgangsqualität → Ist das Ergebnis gut genug?
Beide arbeiten zusammen: Wenn die DoR streng ist, hat das Team weniger Nachfragen im Sprint. Wenn die DoD streng ist, liefert das Team zuverlässig Qualität.
Kann eine Definition of Ready auch schaden?
Ja — wenn sie zu einer Bürokratie-Hürde wird. Manche Teams nutzen die DoR als Ausrede, um Stories abzulehnen: „Nicht ready, können wir nicht machen." Das bremst den Fortschritt und schafft Konflikte zwischen Team und Product Owner.
Die DoR sollte als Hilfestellung verstanden werden, nicht als Mauer. Wenn eine Story zu 90 % ready ist und die offene Frage in 10 Minuten geklärt werden kann, ist das kein Grund, sie aus dem Sprint zu halten.
Übrigens: Die Definition of Ready steht bewusst nicht im offiziellen Scrum Guide. Sie ist eine ergänzende Praxis, die viele Teams hilfreich finden — aber keine Pflicht.