Definition of Ready: Zwischen Klarheit und Flexibilität

Vor einiger Zeit hatte ich die Gelegenheit, ein frisch gegründetes Scrum-Team mit sehr unterschiedlichen Erfahrungsstufen, von Junior bis Senior, zu begleiten. Ich war bei allen Scrum-Events dabei und konnte beobachten, wie jedes Team-Mitglied auf seine ganz eigene Weise arbeitet. Oft sind es kleine Nuancen, die einen großen Einfluss auf das Gesamtergebnis haben können. Besonders ins Auge gefallen ist mir die Definition of Ready (DoR) und wie sie im Team gelebt wurde. Die User Stories waren sehr ausführlich ausgearbeitet, mit Bildern, Akzeptanzkriterien und intensiven Diskussionen in den Kommentaren. Anfangs fand ich es positiv, wie viel Wert auf Nachfragen und Klarheit gelegt wurde. Doch mit der Zeit und weiteren Beobachtungen zeigte sich, dass die DoR im Alltag eher als Gatekeeper diente: Sie entschied darüber, welche Stories in den Sprint aufgenommen werden durften und welche nicht. Die Kriterien waren teilweise so strikt, dass Stories trotz vieler vorhandener Informationen nicht berücksichtigt wurden, obwohl weitere Details auch während des Sprints hätten geklärt werden können, ganz im Sinne des Scrum Guides. Auch Veränderungen an Akzeptanzkriterien während des Sprints wurden als schwierig empfunden, obwohl solche Anpassungen für agile Teams eigentlich normal und wünschenswert sind. Es entstand der Eindruck, dass das Team vor allem Wert auf möglichst vollständige und klar definierte Tickets legte, um effizient arbeiten zu können, was durchaus nachvollziehbar ist. Gleichzeitig ging dabei jedoch etwas von der Flexibilität und Offenheit verloren, die Agilität eigentlich ausmachen.

Die Definition of Ready ist eine Sammlung von Kriterien, die ein Product Backlog Item erfüllen sollte, bevor es in einen Sprint aufgenommen wird. Ziel ist, dass das Entwicklungsteam alle nötigen Informationen hat, um ohne Verzögerungen und Unklarheiten arbeiten zu können. Typische DoR-Kriterien sind klar formulierte Anforderungen, Akzeptanzkriterien, abgeschlossene fachliche Klärung und die Verfügbarkeit aller relevanten Ressourcen.

Interessanterweise ist die DoR kein offizieller Bestandteil des Scrum Guides. Zwar wurde der Begriff „ready“ in früheren Versionen des Guides (ab 2011) eingeführt und mit der Definition of Done gleichgestellt, doch seit der Version 2020 ist „Ready“ deutlich zurückgenommen worden. Der Scrum Guide spricht heute nur noch davon, dass Product Backlog Items „ready for selection“ sein sollten, ohne konkrete Kriterien zu nennen. Diese bewusste Zurückhaltung spiegelt die Scrum-Philosophie wider: Teams sollen selbstverantwortlich entscheiden, wann ein Item ausreichend vorbereitet ist.

Jeff Sutherland, einer der Scrum-Erfinder, definiert „Ready“ sehr pragmatisch: „Ready is when the team says: 'Ah, we got it'“. Damit ist Ready kein starres Regelwerk, sondern ein subjektives, teamspezifisches Gefühl von Klarheit und Umsetzbarkeit.

Klarheit und Orientierung:
Die DoR hilft Teams, ein gemeinsames Verständnis über die Anforderungen zu entwickeln und Missverständnisse zu vermeiden. Sie dient als gemeinsamer Qualitätsmaßstab für gut vorbereitete Items, gerade dann, wenn die Zusammenarbeit mit dem Product Owner schwierig ist oder dieser nicht immer greifbar ist.

Effizientere Planung:
Gut vorbereitete Stories lassen sich zuverlässiger schätzen und umsetzen. Besonders bei wechselnden PBI-Erstellern oder wenn Stories häufig unvollständig oder missverständlich formuliert sind, kann eine DoR helfen, die nötigen Mindeststandards sicherzustellen.

Reduzierte Nacharbeit:
Durch klare Kriterien sinkt das Risiko, dass während des Sprints wesentliche Informationen fehlen. Eine DoR wirkt hier wie ein Sicherheitsnetz, besonders dann wertvoll, wenn Storys regelmäßig in unklarer Qualität im Backlog landen.

Orientierung für unsichere Rollenverteilungen:
In manchen Teams liegt das Schreiben der Stories beim PO, in anderen eher beim Team. Wenn unklar ist, wer was beachten muss, kann eine DoR Transparenz schaffen. Sie hilft den PBI-Erstellern zu verstehen, was alles benötigt wird, um ein Item sprint-reif zu machen.

Gerade für neu gegründete oder noch unerfahrene Teams kann eine schlanke DoR als „Stützrad“ dienen, um Sicherheit und Struktur zu geben.

Die größte Gefahr der DoR liegt darin, dass sie zu einem starren Gatekeeper wird. Wenn Teams darauf bestehen, dass alle Kriterien vollständig erfüllt sein müssen, bevor ein Item in den Sprint darf, entsteht ein sequenzielles, wasserfallähnliches Vorgehen. Das widerspricht dem agilen Prinzip, mit unvollständigen Informationen zu starten und gemeinsam zu lernen. Mike Cohn schreibt dazu zusammengefasst folgendes:

„A definition of ready can lead to a sequential, waterfall approach to getting work done. This occurs when the DoR acts like a gate, blocking certain backlog items from the sprint until all of the pre-work in the DoR is completed.“

Wird die DoR zu einer starren Checkliste, steht sie im Widerspruch zum ersten Wert des Agile Manifesto:

„Individuals and interactions over processes and tools.“

Die Zusammenarbeit und das gemeinsame Lernen werden durch zu viel Prozess und Formalismus ausgebremst.

• Bürokratie und Verzögerungen: Stories werden aus dem Sprint entfernt, weil Kleinigkeiten fehlen, obwohl sie im Sprint leicht geklärt werden könnten. Das kann die Time-to-Market verzögern.
• „Weaponization“ der DoR: Teams können die DoR als Ausrede nutzen, um unliebsame Stories abzulehnen („Erfüllt nicht die DoR“), was zu einer ungesunden Teamdynamik führt.
• Verlust der Entdeckerfreude: Das Team konzentriert sich auf perfekte Tickets statt auf gemeinsames Lernen und iterative Entwicklung.

Eine wissenschaftliche Studie zeigt: Während einige Teams von der DoR profitieren, berichten andere von Implementierungsproblemen und einer Tendenz zu Waterfall-Denken. Von drei untersuchten Teams nutzte nur eines die DoR explizit und das eher implizit. Die Praxis zeigt also, die DoR ist kein Allheilmittel und kann sogar hinderlich sein, wenn sie falsch eingesetzt wird.

Statt sequentieller Gates empfiehlt sich „Concurrent Engineering“: Teams starten mit dem, was da ist, und klären offene Punkte parallel zur Entwicklung. So bleibt man beweglich und kann schneller auf neue Erkenntnisse reagieren.

Backlog Refinement sollte ein gemeinsamer, kontinuierlicher Prozess sein, bei dem Product Owner und Team zusammenarbeiten, um Stories zu klären, nicht ein Kontrollmechanismus, der Tickets abblockt5.

Viele Teams orientieren sich an den INVEST-Kriterien (Independent, Negotiable, Valuable, Estimatable, Small, Testable). Diese bieten eine flexible Orientierung, ohne zu starr zu werden.

Die DoR ist nicht grundsätzlich schlecht. Sie kann in folgenden Situationen hilfreich sein:

• Als temporäre Orientierungshilfe für neue Teams
• Als leichtgewichtige, gemeinsam entwickelte Richtlinie
• Wenn sie regelmäßig reflektiert und angepasst wird

Wichtig: Die DoR sollte niemals als Vertrag oder starres Regelwerk verstanden werden, sondern als lebendiges Working Agreement, das dem Team dient und nicht umgekehrt.

Prüfe kritisch, ob überhaupt eine DoR notwendig ist: Nicht jedes Team braucht zwingend eine Definition of Ready. Manchmal verbirgt sich hinter dem Wunsch nach vielen klaren Kriterien eine große Angst vor Fehlern oder Unsicherheiten im Team. In solchen Fällen lohnt es sich, das Thema psychologische Sicherheit in den Fokus zu nehmen: Fühlen sich alle im Team sicher genug, um Fragen zu stellen, Unklarheiten zuzugeben oder Fehler zu machen?

Kritisch hinterfragen: Beobachte, ob die bestehende DoR tatsächlich die Zusammenarbeit fördert oder eher als Gatekeeper wirkt, der Stories blockiert und Prozesse verkompliziert.

Regelmäßig reflektieren: Die DoR gehört regelmäßig in die Retrospektive: Was hilft uns, was bremst uns? Brauchen wir noch alle Kriterien? Was können wir vereinfachen?

Warnsignale erkennen: Werden Stories häufig wegen Kleinigkeiten abgelehnt? Gibt es Schuldzuweisungen, Frust oder lähmende Diskussionen über die Einhaltung der DoR? Dann ist sie möglicherweise zu starr oder wird falsch eingesetzt.

Fokus auf Zusammenarbeit: Die Verantwortung für „Ready“ liegt beim gesamten Team, nicht nur beim Product Owner. Die beste DoR ist ein gemeinsam getragenes Agreement, das echte Kollaboration ermöglicht, nicht ein Werkzeug, um sich gegenseitig Verantwortlichkeiten zuzuschieben.

Die Definition of Ready kann für Klarheit und Struktur sorgen, besonders in jungen oder unsicheren Teams. Doch sobald sie zu starr oder formalistisch wird, droht sie, die Agilität zu ersticken und Teams in alte Wasserfall-Muster zurückzuwerfen. Der Scrum Guide verzichtet bewusst auf eine feste DoR und das aus gutem Grund. Die besten Teams nutzen die DoR nicht, und wenn, dann nur als flexible Orientierung, nicht als starre Eintrittskarte. Sie setzen auf Zusammenarbeit, Kommunikation und kontinuierliches Lernen, die wahren Grundlagen agiler Entwicklung.