In einem anderen Artikel haben wir die Defintion of Ready und die Definition of Done bereits vorgestellt. Die Defintion of Ready (DoR) stellt eine Art Einlasskontrolle für Product Backlog Items dar. Erst wenn die Kriterien der DoR erfüllt sind, kann ein Product Backlog Item für das Sprint Backlog verwendet werden. Durch die Scrum INVEST Methode lassen sich mit Hilfe des Akronyms INVEST die Kriterien an ein Product Backlog Item in Kategorien erfassen.
Was sind Product Backlog Items?
Alle Aufgaben, die das Team umsetzen wird und die für die Entwicklung des Produkts relevant sind, werden Product Backlog Item genannt. Sie sind Bestandteil des Product Backlogs, welches in der Regel durch den Product Owner gepflegt wird.
Sehr häufig werden User Stories dafür eingesetzt. Kurz gesagt, beschreiben User Stories die Aufgabe aus Anwendersicht und geben den Nutzen der Aufgaben wieder. Meistens wird dafür ein Template (Als Nutzer möchte ich Funktion, um Wert zu erreichen) eingesetzt, was aber keine Voraussetzung dafür ist. Neben User Stories kommen auch sehr häufig Tasks, Subtasks, Bugs und Assets zum Einsatz.
Für den Beitrag hier beziehen wir uns hauptsächlich auf User Stories. Die Definition of Ready kann auch auf die anderen Arten der Product Backlog Items eingesetzt werden. Doch meistens gibt es dann je nach Item-Art eine unterschiedliche DoR.
Wozu wird die DoR benötigt?
Die DoR beschreibt den Reifegrad einer User Story. Erst wenn alle Kriterien der DoR erfüllt sind, darf sie in das Sprint Backlog übernommen werden. Das Scrum Team (vor allem der Product Owner und die Developer) beschreibt die DoR. Sie wird stets im Rahmen der Retrospektive auf Vollständigkeit und Sinnhaftigkeit hin überprüft und ggf. angepasst.
Die DoR dient dazu, gewisse Standards in der Beschreibung einer User Story sicherzustellen. Dies soll vermeiden, dass die Developer während des Sprints zu viel Zeit für Nachfragen und Klärung der Anforderungen aufbringen müssen.
Ein Meeting zur Prüfung der DoR ist das Estimation Meeting. In diesem Meeting werden neue und/oder bestehende User Story besprochen und auf die Erfüllung der DoR hin überprüft. Sind sie ausreichend vorbereitet, können sie in das Sprint Planning bzw. in den Sprint kommen.
DoR ersetzt nicht die Kommunikation
Das Scrum Team sollte die DoR nicht als Ersatz für Kommunikation ansehen. Trotz ausgefeilter DoR steht die Kommunikation zwischen dem Product Owner und den Developern weiterhin im Fokus. Die Definition of Ready ist lediglich eine (knappe) Checkliste, sie sowohl Product Owner als auch Developer bei der Formulierung von User Stories unterstützt.
Die Scrum INVEST Methode
Um die Definition of Ready zu formulieren, kannst Du Dich den INVEST-Kriterien bedienen. Im Folgenden werden die einzelnen Scrum Invest Kriterien vorgestellt.
Independent
Der Vorteil unabhängiger User Stories ist, dass User Stories frei priorisiert und im Zweifel sogar aus dem Product Backlog heraus genommen werden können, ohne das übrige Product Backlog groß zu beeinflussen.
Negotiable
User Stories sollten aussagekräftig mit den notwendigen Details beschrieben werden. Allerdings sollten User Stories keine Lösungen vorgeben und noch Raum für Diskussionen zwischen Scrum Developer und Kunde lassen.
Valuable
Eine User User stellt für sich einen Wert dar. Wird die User User Story umgesetzt, so wird eine Wertsteigerung im zu entwickelnden Produkt erzielt.
Estimatable
Nur wenn eine User Story durch das Scrum Developer Team geschätzt worden ist, kann es in das Spirnt Backlog aufgenommen werden.
Sized appropiately
Eine User Story sollte genau so groß sein, dass sie im Rahmen eines Sprints umgesetzt werden kann.
Testable
Jede User User Story sollte für sich testbar sein. Dazu werden Acceptence Criteria / Akzeptanzkriterien definiert, die durch die Scrum Developer und dem Product Owner auf ihre Einhaltung hin überprüft werden.
Das INVEST-Akronym zur Beschreibung der DoR zur Rate zu ziehen, ist eine Möglichkeit. Ein jedes Scrum Team muss für sich selbst eine passende DoR entwickeln und diese kontinuierlich überprüfen. Die DoR sollte schlank gehalten werden und nicht in einen langen Prozess oder Worklfow münden.
Beispiel einer Definition of Ready
Im Nachfolgenden ein Beispiel basierend auf Scrum INVEST:
- Max. 1 Abhängigkeit zu einer anderen User Story
- Beschreibt das „Was“ (aber nicht das „Wie“)
- Der Business Value wurde eingetragen
- Die User Story wurde durch die Developer geschätzt
- Die User Story kann im Rahmen eines Sprints umgesetzt werden
- Akzeptanzkriterien sind vorhanden
Anleitung zum Erstellen der Definition of Ready
- Starte mit einfachen Regeln
Ihr könnt als Team zum Beispiel definieren, dass die Beschreibung der User Story ausgefüllt wurde und die User Story in einem Sprint umsetzbar ist.
- Ergänze aus Learnings
Nutze die Retrospektive, um auch auf die Qualität der User Stories zum Start eines Sprints zu gucken. Nutze die Learnings und erweitere die DoR entsprechend.
- Ergänze Qualitätsstandards
Wenn das nicht bereits durch die Learnings reinkommt, kannst du nach ein paar Sprints Qualitätsstandards hinzufügen.
Bei Bugs zum Beispiel dass eine Problembeschreibung enthalten ist und Schritte zur Reproduzierbarkeit.
Bei User Stories könnten das ausgefüllte Akzeptanzkriterien sein, durchgeführtes Review durch die Developer und vor dem Planning geschätzt.
Darum solltest Du keine DoR anwenden
Die DoR darf niemals als Ausrede dafür genommen werden, dass eine User Story nicht in den Sprint genommen werden kann. Wenn die User Story nicht ready ist, kann sie nicht umgesetzt werden. Oftmals ist der wahre Grund für die Ablehnung einer User Story nicht die unerfüllte DoR, sondern ein Konflikt zwischen Product Owner und Developer.
Zudem kann das zu strikte Befolgen der DoR dazu führen, dass notwendige User Stories aufgrund von Formalitäten nicht umgesetzt werden. Das kann zu Zeitverzug, Budgetproblemen oder sonstigen negativen Auswirkungen führen.
Diese und weitere Gründe könnten Argumente dafür sein, die DoR nicht zu verwenden oder weiter zu verschlanken. Die DoR kann als eine Art Agenda verstanden werden, um in den Austausch zwischen Product Owner und Developer zu kommen.
Unser Angebot zur DoR
Wir unterstützen Scrum Teams, Scrum Master und Product Owner durch Inhouse Schulungen und Scrum Coaching.
Scrum Inhouse Schulung
Die Scrum Inhouse Schulungen werden dabei individuell konzipiert und durchgeführt. Der Ablauf ist wie folgt:
- Kostenloses Erstgespräch, um Anforderungen aufzunehmen
- Schriftliche Angebotserstellung
- Bei Zusage: Individuelle Konzeption der Inhouse Schulung
- Ggf. Absprache per MS Teams zum Inhalt
- Durchführung der Schulung vor Ort, online, an einem oder mehrere Tage oder in halben Tagen parallel zur Arbeit
- Zur Nachbereitung wird ein Fotoprotokoll erstellt
Scrum Coaching
Beim Scrum Coaching handelt es sich aus einer Kombination aus individuellem 1:1 Training und Business Coaching. Der Ablauf im Coaching ist wie folgt:
- Du kannst direkt das 5S-Paket über elopage kaufen. Den Link findest du unterhalb der Liste.
- Anschließend vereinbarst Du den ersten Termin und gibst dabei an, was Dein Ziel des Scrum Coachings sein wird.
- In der ersten Session evaluieren wir deine aktuellen Herausforderungen und beruflichen Ziele.
- Die Sessions 2 bis 4 dienen zum Scrum-Training. Ich gebe Dir nützliche Tools und Tricks aus der Praxis für die Praxis mit.
- In der 5. Session schließen wir das Paket ab. Wir validieren Deine beruflichen Ziele und Du bewertest den Methodenkoffer.
Das könnte Dich auch interessieren: