INVEST Scrum – Definition of Ready

invest

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 eine User Story in Kategorien erfassen.

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

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

Darum sollten Sie 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 und Product Owner durch Inhouse Schulungen und Scrum Coaching. Sprechen Sie uns an, wenn Sie mit uns gemeinsam Ihre DoR ausarbeiten möchten.

Haben Sie noch Fragen zur INVEST Methode? Wir beantworten diese gerne in den Kommentaren! 🙂

Das könnte Sie auch interessieren:

Patric Eid

Patric Eid

Als selbstständiger Projektberater und Trainer verhelfe ich Unternehmen zu mehr Klarheit und Struktur in ihrem Projektmanagement. Zudem unterstütze ich Projektleiter:innen und Product Owner in der 1:1-Arbeit als Agile und Business Coach. Meine Themenschwerpunkte sind Projektmanagement und Anforderungsmanagement. Zudem führe ich Anwender-Schulungen beispielsweise mit Jira, Confluence oder pqforce durch. Meine Seminare haben aufgrund von umfangreichen praktischen Erfahrungen in unterschiedlichen Branchen und Projektrollen einen hohen Praxisbezug.

Jetzt unverbindlich Klarheit im Projekt gewinnen:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on xing
XING
Share on email
Email

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.