Die Definition of Ready ist eine Sammlung von Vereinbarungen, die das Scrum Team trifft. Sie dient der Entscheidung darüber, welche Items soweit sind, dass Sie vom Entwicklungsteam im Sprint verarbeitet werden können. Das ist wichtig, weil das Ziel von Scrum Teams darin besteht, so schnell wie möglich die Items mit dem größten Mehrwert umzusetzen. Gute Vereinbarungen über die Qualität der User Stories ermöglichen es dem Entwicklungsteam, diese User Stories schneller anzugehen und schneller fertigzustellen.
Was bedeutet die Definition of Ready?
Im Scrum Guide kommt der Term Definition of Ready nicht vor. Trotzdem verwenden ihn viele Scrum Teams in der Praxis. Im Scrum Guide ist nur die Rede von Product Backlog Items, die so vorbereitet sind, dass das Entwicklungsteam sie übernehmen kann. Wie entschieden wird, wann ein Item soweit ist, besagt der Guide nicht.
Eine Definition of Ready kann einem Scrum Team dabei helfen, Vereinbarungen festzulegen, anhand derer sich bestimmen lässt, welche Items vom Entwicklungsteam im Sprint bearbeitet werden können. Ein wichtiges Hilfsmittel. Denn mithilfe der Definition of Ready lässt sich sicherstellen, dass die Items mit der höchsten Priorität so schnell wie möglich ausgeliefert werden können. Wenn deutlich ist, welchen Qualitätsansprüchen User Stories gerecht werden sollen, kann das Entwicklungsteam sie schneller angehen. Auch die für die Umsetzung der User Stories benötigte Zeit wird minimiert.
Das Scrum Team einigt sich auch auf eine Definition of Done. Sie besagt, welche Items im Verlauf eines Sprints fertiggestellt wurden. Die Definition of Ready ist eine ähnliche Sammlung von Vereinbarungen.
Weshalb ist es ratsam, eine Definition of Ready zu verwenden?
In der Praxis kommt es immer wieder vor, dass Product Ownern das Formulieren von Product Backlog Items schwerfällt. In der Regel werden sie in Form sogenannter User Stories aufgeschrieben
User Stories haben den folgenden Aufbau:
Als [Stakeholder] möchte ich [Wunsch], damit [Grund für den Wunsch, Lösung für das Problem].
Eine der Herausforderungen, mit denen Product Owner beim Formulieren von User Stories zu kämpfen haben: Im Vorhinein muss richtig eingeschätzt werden, ob eine User Story genügend Informationen enthält, um dem Entwicklungsteam ein vollständiges Bild davon zu vermitteln, was sich der Stakeholder wünscht. Dabei muss der Product Owner ein subtiles Gleichgewicht finden. Denn sie oder er muss das Entwicklungsteam mit genügend deutlichen Informationen bezüglich des “Was“ versorgen. Aber ohne vorzuschreiben, “wie“ dieser Wunsch umgesetzt werden soll.
Außerdem fällt es oft schwer zu verhindern, dass eine User Story zu groß wird. Product Owner und Stakeholder haben häufig viele und große Wünsche. Das Entwicklungsteam hingegen benötigt kleinteiligere Aufgaben, die im Rahmen eines Sprints abgearbeitet werden können. Auch hier geht es darum, für Gleichgewicht zu sorgen. Einerseits muss eine User Story klein genug sein, damit aus ihr ein Mehrwert geschaffen werden kann. Andererseits muss das ausgelieferte Produkt von ausreichend großem Wert für die Stakeholder sein.
In einer Definition of Ready werden die Vereinbarungen festgelegt, die der Product Owner mit dem Entwicklungsteam getroffen hat, um die genannten Herausforderungen zu meistern. Oft ist die Definition of Ready eine Liste zum Abhaken. Anhand ihrer kann der Product Owner Punkt für Punkt überprüfen, ob die User Story die gestellten Anforderungen erfüllt.
Wie wird eine Definition of Ready entwickelt? Die Verwendung von INVEST.
Wie beschrieben handelt es sich bei der Definition of Ready um eine Festlegung von Vereinbarungen zwischen dem Entwicklungsteam und dem Product Owner.
Eine bewährte Vorgehensweise Gespräche hierüber zu führen und die Definition of Done zu formulieren, verbirgt sich hinter dem Akronym INVEST. Dieses Akronym steht für:
Independent (unabhängig) – User Stories dürfen so wenig wie möglich Abhängigkeiten von anderen User Stories aufweisen. Auch Abhängigkeiten von anderen außerhalb des Scrum Teams sind so weit wie möglich zu vermeiden.
Negotiable (verhandelbar) – Jede User Story muss ausreichend weit gefasst sein. So kommt ein Gespräch zwischen dem Entwicklungsteam und dem Product Owner darüber in Gang, was genau zu entwickeln ist. Eine User Story sollte also kein in Stein gemeißeltes Bündel von Anforderungen sein.
Valuable (wertvoll) – Die User Story muss einen Wert liefern. Es mag überflüssig erscheinen, das explizit zu erwähnen. Aber es kann durchaus passieren, dass eine User Story, die in einem früheren Stadium aufgeschrieben wurde, in dem Moment überholt ist, in dem die sie neu besprochen wird. Und dass die User Story dann keinen Wert mehr liefert.
Estimable (schätzbar) – Um einschätzen zu können, mit wie viel Aufwand die Umsetzung verbunden sein wird, muss das Entwicklungsteam genügend Informationen über die Wünsche des Stakeholders erhalten haben. Oft wird der ungefähre Zeitaufwand mittels relativer Schätzungen beispielsweise anhand von Planning Poker ermittelt.
Small (klein) – Alle User Stories müssen klein genug sein, damit sie innerhalb eines Sprints umgesetzt werden können. Denn bekanntlich muss zum Ende jedes Sprints ein inkrementeller Teil des Projekts fertiggestellt werden. User Stories, für die das Entwicklungsteam schätzt, dass die Erarbeitung mehr als einen Sprint in Anspruch nehmen wird, muss der Product Owner zerlegen.
Testable (testbar) – Die ausgelieferte Arbeit muss abgeschlossen und im Prinzip an Kunden übergeben werden können. Entsprechend muss es möglich sein zu testen, ob die Umsetzung planmäßig erfolgt ist. Um diese Prüfungen durchführen zu können, werden vom Product Owner deutlich formulierte Akzeptanzkriterien benötigt. Ihnen muss das Arbeitsergebnis entsprechen. Nur dann hat es einen Wert für die Stakeholder.
Mit den obenstehenden INVEST-Kriterien kann der Grundstein für eine eigene Definition of Ready gelegt werden. Machen Sie sich diese Kriterien zunutze, um gemeinsam zu entscheiden, welche Varianten für den Arbeitsalltag Ihrer Organisation in Frage kommen. Jedes Scrum Team legt andere Kriterien zugrunde und erstellt seine eigene Definition of Ready.
Bitte vergessen Sie nicht, die Definition of Ready regelmäßig zu hinterfragen und bei Bedarf zu überarbeiten. Eine gute Gelegenheit hierfür ist beispielsweise die Sprint Retrospective.
