Die Gefahr
Mitunter wird die Definition of Ready 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 Definition of Ready 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 Definition of Ready mehr Vorgaben für die Formulierung von User Stories zu machen. Im schlimmsten Fall wird die Definition of Ready eine sehr lange Checkliste für den Product Owner. Dann kommt es vor, dass das Entwicklungsteam sich weigert, 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.
Diese Art des Umgangs mit der Definition of Ready 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 Definition of Ready 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 Definition of Ready auf gemeinsames Verständnis fokussieren.
Entwicklung der Definition of Ready
Die Definition of Ready 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 Definition of Ready und Definition of Done umgekehrt zueinander: Das Team wird mit der Zeit immer fähiger. Dadurch kann es zum Sprintende mehr zusichern - die Definition of Done wird umfangreicher. Gleichzeitig braucht das Team immer wieder Vorarbeiten von Anderen vor dem Sprint - die Definition of Ready wird immer schlanker.
