DoR mittels INVEST

In diesem Artikel https://agile-pm.de/2019/02/20/defintion-of-ready-und-definition-of-done/ wurde die Defintion of Ready vorgestellt. Die Defintion of Ready (DoR) stellt eine Art Einlasskontrolle für Product Backlog Items dar. Erst wenn die Kriterien erfüllt sind, kann ein Product Backlog Item für das Sprint Backlog verwendet werden. Mit Hilfe des Akronyms INVEST lassen sich die Kriterien an eine User Story in Kategorien erfassen.

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.

Defintion of Ready und Definition of Done

Die Defition of Done (DoD), oder auch Level of Done (LoD) genannt, bestimmt wann eine User Story als done bezeichnet werden darf. Die Definition of Ready (DoR) bestimmt, ob ein Product Backlog Item ausreichend beschrieben ist, um es in ein Sprint Backlog aufzunehmen. Beide Definitionen haben zum Ziel die Story-Qualität zu erhöhen um damit ein besseres Produkt-Ergebnis zu erzielen.

Interne und externe Anforderungen


Die Definition of Done beinhaltet dabei sowohl Punkte aus der Organisation heraus als auch teamspezifische Anforderungen.

Aus der Organisation kann zum Beispiel die Anforderung entstehen, dass Code Reviews zwingend erforderlich sind. Als Anforderung aus dem Team könnte zum Beispiel der Push in den Master Git-Branch als Anforderung definiert werden.

Diese Anforderungen gelten global für alle Product Backlog Items des Teams.

DoD: ein Team-Angelegenheit

Im Verlauf des Sprints werden die einzelnen Punkte des DoD abgehakt, bis alle berücksichtigt worden sind. Das Scrum Development Team ist zuständig für die Einhaltung des DoD.

Hat das Team die Story verstanden?

Anders als das DoD beinhaltet die Definition of Ready Kriterien an Product Backlog Items. Erst wenn diese Kriterien erfüllt sind, kann eine User Story in den aktuellen Sprint des Teams übernommen werden.

Die DoR stellt dabei allerdings keine Einlasskontrolle für das Sprint Planning 1 dar, sondern auch im Rahmen des SP1 kann die DoR erfüllt werden.

Product Owner füllt DoR aus

Der Product Owner ist zuständig für die Erfüllung des DoR und sorgt somit für die Qualität der Product Backlog Items. Inhalte eines DoR können zum Beispiel sein:

  • Die User Story ist formal beschrieben
  • Acceptance Criteria wurden definiert
  • Der Umfang der User Story ist klein genug, so dass sie in einem Sprint umgesetzt werden kann
  • Die User Story wurde geschätzt