In Teil 2 der Inspektionsserie über Dinge, die im gelebten Scrum zu sehen sind, befasse ich mich heute mit der Definition of Ready (DoR) und ihrem Einsatz bei der Arbeit mit Product Backlog Items.
Beginnen wir direkt: Der Scrum Guide kennt keine Definition of Ready. Der einzige Hinweis auf dieses Thema findet sich im Abschnitt über das Product Backlog:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.
Die Abschnitte "items that can be Done [...] are deemed ready for selection" deuten auf Kriterien hin, die zu erfüllen sind. Wie so oft lässt der Scrum Guide offen, was genau dies ist. Es ist unklar, was "can be Done" für das Scrum Team bedeutet.
Die Definition of Ready stellt somit eine Möglichkeit dar, diese Unklarheit zu beseitigen.
Starten wir zunächst mit einem Blick auf die Herkunft der DoR.
Die erste Definition im Umfeld von Scrum kommt wahrscheinlich von Richard Kronfält:
[...] I think we need a similar mechanism for the work taken in to the sprint. A mechanism which ensures that the stories taken in is really ready to be taken in. Let’s call this state “Ready-Ready”.
Die erste Erwähnung im Umfeld eines offiziellen Scrum-Trainings scheint von Serge Beaumont zu stammen:
In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.
READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the "supplier" is the Team and the "client" is the Product Owner, it's the other way around with the Definition of READY: the Team is the "client" and the Product Owner is the "supplier".
Welche Kriterien machen nun die DoR aus?
Die Agile Alliance beschreibt die DoR wie folgt:
[...] in the Definition of Ready, the team makes explicit and visible the criteria [...] that a user story must meet prior to being accepted into the upcoming iteration.
Der weiter oben verlinkte Artikel von Kronfällt wird konkreter und sieht als Punkte der DoR:
Dagegen betrachtet der Artikel von Beaumont die DoR auf einer abstrakteren Ebene:
Diese Beschreibungen kommen entsprechend einem Muster wie INVEST sehr nahe.
All das sind selbstverständlich nur Denkanstöße und mögliche Ausprägungen. Welche davon zum Einsatz kommen, hängt von Unternehmen, Produkt, Team und weiteren Faktoren ab.
Und was bringen diese Kriterien dem Scrum-Team?
Die Agile Alliance erwartet diese Vorteile bei der Nutzung einer DoR:
Die DoR macht also klarer, ab wann ein Scrum-Team sinnvoll Arbeit in die Umsetzung einer Anforderung investieren kann.
Im realen Einsatz gibt es jedoch einen schmalen Grat zwischen der DoR als Denk- bzw. Diskussionshilfe und einer restriktiven Nutzung.
Im Folgenden gebe ich Beobachtungen wieder. Es handelt sich nicht um Allgemeinaussagen. Die Arbeitswelt ist vielfältig und jedes Team ist anders.
In meinen Augen liegt die große Gefahr in einer zu starren Auslegung der DoR. Je nach gewählter Ausprägung kann sie eine starke Checklisten-Neigung bzw. einen Lastenheft-Charakter annehmen. Dieses Risiko steigt, wenn in einem Ticket-System freier Wahl eine Vorlage für Items angelegt wird, welches ausführlich die gewünschten Inhalte auflistet.
Dabei ist im Kern nichts gegen Vorlagen auszusetzen, wenn sie als Unterstützung gesehen werden und nicht als fixes Regelwerk.
Der feine Unterschied ist, dass die DoR zeigt, wie eine gute Anforderung aussehen kann. Sie muss jedoch nicht immer gleich aussehen. Entsprechend ist z. B. eine nicht komplett ausgefüllte Vorlage kein automatischer Grund, eine Anforderung abzulehnen.
Ein solches Vorgehen stünde im Widerspruch zu mindestens zwei Werten des Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Und ein solches Verhalten bräche mit mindestens zwei Prinzipen der Agilität:
Business people and developers must work together daily throughout the project.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Genau hier zeigt sich wieder, dass die Rückbesinnung auf die Kernwerte der agilen Zusammenarbeit hilft, ein Werkzeug zu verstehen und einzuordnen.
Die Definition of Ready kann ein weiteres gutes Werkzeug sein, um Struktur in einem komplexen Umfeld zu geben.
Wenn sie richtig als Denk- und Kommunikationshilfe eingesetzt wird.
Denn auf der einen Seite können schlechte Anforderungen ein Zeichen für eine Dysfunktion sein. Und genauso kann auf der anderen Seite eine zu restriktive Handhabung der DoR und damit verbundene Hindernisse bei der Zusammenarbeit Warnsignale darstellen.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.