Die Definition of Ready (auch kurz auch DoR) ist ein von vielen Scrum Teams genutztes Tool, mit dem Unklarheit im Sprint verhindert werden soll. Hier erfährst Du, was genau dahintersteckt und warum Du besser auf sie verzichten solltest.
Woher kommt die Idee der Definition of Ready?
Der Ursprung der Definition of Ready liegt in diesem Satz des Scrum Guides:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
Die Idee, die also hinter der Definition of Ready steckt, ist:
Nur diejenigen Product Backlog Items dürfen für den nächsten Sprint eingeplant werden, die auch ausreichend klar, verstanden und klein genug sind.
Bei den meisten Scrum Teams hat sich die sogenannte INVEST-Formel eingebürgert. Erst wenn eine User Story diesen Kriterien entspricht, ist sie sprint ready.
Darüber hinaus könnt Ihr natürlich noch weitere Kriterien für eine Definition of Ready festhalten. Beispielsweise „Die User Story muss Akzeptanzkriterien besitzen“ und dergleichen mehr.
Wann kommt die Definition of Ready zum Einsatz?
Die Definition of Ready kommt zu zwei verschiedenen Anlässen zum Einsatz. Und zwar zum einen beim Product Backlog Refinement und zum anderen beim Sprint Planning.
Die DoR im Backlog Refinement
Das Product Backlog Refinement dient der gemeinsamen Pflege des Backlogs durch Dein Scrum Team. Unter anderem sorgt es dafür, dass diejenigen Product Backlog Items, die sich weit oben im Backlog befinden, möglichst gut verstanden sind und innerhalb eines Sprint umgesetzt werden können.
Die Definition of Ready soll Scrum Teams dabei helfen, diesen Zustand herzustellen. Sie stellt gewissermaßen einen gemeinsamen Kriterienkatalog dar, wann ein Backlog Item ausreichend refined bzw. sprint ready ist. So kann die DoR beispielsweise auch verhindern, dass wichtige Dinge vergessen werden.
Die DoR im Sprint Planning
Mehr dazu findest Du auch in meinem Beitrag zum Unterschied zwischen der DoD und DoR.
Die Definition of Ready ist der erste Schritt in Richtung Wasserfall
Stell Dir vor, Dein Team präsentiert in der Sprint Review die neuste Funktion des letzten Sprints. Ihr erhaltet viel hilfreiches Feedback von Euren Teilnehmern und es werden jede Menge neue Ideen generiert. Von einer Idee sind dabei alle begeistert und Ihr seid Euch einig, dass es wichtig wäre, diese Idee so schnell wie möglich umzusetzen.
Nur werdet Ihr leider keine Gelegenheit haben, diese Idee ausreichend zu besprechen, da nach der Review (bzw. Sprint Retrospektive) direkt Euer Sprint Planning beginnt. Demnach dürftet Ihr nicht mit der Arbeit an diesem Feature beginnen, obwohl sich alle einig sind, dass es der sinnvollste nächste Schritt wäre. Der Product Owner schreibt das Feedback daher in sein Product Backlog, wo sie schlimmstenfalls lange schlummern wird.
Damit bewegt eine Definition of Ready Euer Scrum Team gefährlich in Richtung Wasserfall-Denken. Denn schnell habt Ihr dort Dinge festgehalten, mit denen Ihr die spontane Umsetzung neuer Features torpediert:
Die DoR als Gatekeeper
Damit mutiert eine Definition of Ready schnell zum Gatekeeper und verhindert Spontaneität und letztlich sogar agiles Arbeiten selbst. (Im Artikel auf t2informatik ist die DoR sogar als schwarzer Trennbalken eingezeichnet.) Sie gibt den Entwicklern ein Werkzeug in die Hand, mit dessen Hilfe sie alles ablehnen können, was nicht haargenau dem Kriterienkatalog entspricht. Das ist gerade bei potenziellen Konflikten zwischen Product Ownern und Entwicklern problematisch bzw. lässt diese erst entstehen.
Muss überhaupt alles „sprint ready“ sein, um zu beginnen?
Natürlich ist es sehr wünschenswert, jeden Sprint immer mit möglichst viel Klarheit zu beginnen. Und jedes Scrum Team sollte darauf hinarbeiten, ein sauberes Product Backlog zu besitzen, in dem die weit oben befindlichen Backlog Items gut verstanden, klar und klein genug für einen einzelnen Sprint sind.
Das ist nur in der Praxis nicht immer möglich. (Und auch gar nicht notwendig.) Ein gewisser Anteil an Ungewissheit im Sprint Planning bzw. Sprint Backlog ist vollkommen in Ordnung, solange ausreichend Klarheit für die ersten Tage des kommenden Sprints herrscht.
Ein exzellentes Scrum Team kann fehlende Klarheit auch während des Sprints herstellen.
Das bedeutet, dass Du mit Deinem Team durchaus vorher nicht besprochene User Stories in den kommenden Sprint einplanen kannst. Sie werden dann sozusagen „on the flow“ in Refinements besprochen und direkt danach umgesetzt.
Selbstverständlich sollte auch das kein Dauerzustand sein. Falls permanent zu viel Unklarheit im Sprint Planning herrscht, solltet Ihr das in Eurer Sprint Retrospektive gemeinsam thematisieren. Aber Ihr solltet Wege finden, mit Ungewissheit umzugehen, statt sie mit Hilfe einer Definition of Ready aus Eurem Sprint zu verbannen.
Und vielleicht solltet Ihr auch noch einmal gemeinsam über den Scrum Wert Courage sprechen.
