Definition of Ready

Die Idee

Die Definition of Done (DoD) ist ein etabliertes Scrum-Konzept: Das Scrum-Team definiert über die DoD, wann alle Arbeiten an einem Product Backlog Items (z.B. User Story) fertig gestellt sind, so dass keine Nacharbeiten mehr notwendig sind. Dies ist in der Regel auch das Kriterium, dass diese Items im Sprint Review demonstriert werden dürfen.

Das Konzept der Definition of Ready (DoR) ist nicht ganz so verbreitet ist wie die DoD. Die DoR definiert, wann ein Product Backlog Item (z.B. User Story) soweit ausgearbeitet ist, dass es in den Sprint "darf". Über die DoR soll sichergestellt werden, dass Product Backlog Items ausreichend vorbereitet in den Sprint kommen und während der Entwicklung nicht ständig der Arbeitsfluss unterbrochen werden muss, weil Dinge unklar, die das Team nicht selbst klären kann.

Die Gefahr

Mitunter wird die DoR allerdings auf eine Art und Weise verwendet, die aus agiler Sicht ungünstig ist. Dann wird ein überregulierter Prozess zwischen Product Owner und Entwicklungsteam etabliert, wo stattdessen eng kooperiert werden sollte.

Dieser Effekt tritt schnell ein, wenn man versucht, Zusammenarbeitsprobleme zwischen Product Owner und Entwicklungsteam durch Erweiterung der DoR zu lösen. Vielleicht ist der Product Owner im Sprint Review unzufrieden mit dem Produktinkrement und die Ursache ist mangelndes Verständnis des Entwicklungsteams zu einer User Story. Dann mag das Entwicklungsteam versucht sein, dem Product Owner über die DoR mehr Vorgaben für die Formulierung von User Stories zu machen. Im schlimmsten Fall wird die DoR eine sehr lange Checkliste für den Product Owner und das Entwicklungsteam weigert sich, mit dem Product Owner über eine User Story zu sprechen, solange die Checkliste nicht abgehakt ist - am Besten noch mit Unterschrift des Vorgesetzten des Product Owners.

Dieser Art des Umgangs mit der DoR passt weder zu Scrum noch zu Agilität.

Das Agile Manifest hat ein paar Dinge über das Verhältnis zwischen Product Owner und Entwicklungsteam zu sagen:

  • “Individuals and interactions over processes and tools”
  • “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.”
  • “The best architectures, requirements, and designs emerge from self-organizing teams.”

Ein besserer Umgang mit der Definition of Ready

Die DoR sollte schlank sein und wenig Vereinbarungen enthalten. Die Vereinbarungen sollten auf die Zusammenarbeit fokussieren und nicht auf Artefakte:

  • "Gemeinsames Verständnis der User Story im Refinement hergestellt" ist wirksamer als "Anforderung liegt in User Story-Satzform vor".
  • "Akzeptanzkriterien wurden gemeinsam im Refinement vereinbart" ist wirksamer als "mind. 5 Akzeptanzkriterien vorhanden".

Schließlich sind die Artefakte (z.B. User Stories) zu diesem Zeitpunkt im Prozess nur Mittel zum Zweck. Sie sollen dazu dienen, ein gutes gemeinsames Verständnis herzustellen. Folglich sollte die DoR auf gemeinsames Verständis fokussieren.

Entwicklung der Definition of Ready

Die DoR ist keine statische Vereinbarung. Team und Product Owner lernen gemeinsam, wie die DoR effektiver gestaltet werden kann. Änderungen der DoR werden meist über Retrospektiven initiiert.

Faktisch entwickeln sich DoR und DoD (Definition of Done) umgekehrt zueinander: Das Team wird mit der Zeit immer fähiger. Dadurch kann es zum Sprintend mehr zusichern - die DoD wird umfangreicher. Gleichzeitig braucht der Team immer wieder Vorarbeiten von Anderen vor dem Sprint - die DoR wird immer schlanker.

Unser Angebot zur Definition of Ready

Wir coachen Team und Product Owner, wie sie passende DoR und DoD finden und diese systematisch weiterentwickeln.

Treten Sie mit uns in Kontakt.