Definition of Ready
 |
| Bild: Pixabay / DCG:MAK - Lizenz |
Unter ihr versteht man üblicherweise eine Liste von Kriterien die erfüllt sein müssen bevor eine Anforderung zur Umsetzung in einen Sprint übernommen wird. Häufig anzutreffen sind z.B. "Alle Teammitglieder müssen die Anforderung verstanden haben", "Es müssen validierbare Akzeptanzkriterien formuliert sein" oder "Die Umsetzung dieser Anforderung muss einen erkennbaren Mehrwert erzeugen".
Der Hintergrund der DoR ist schnell erkennbar. Mit ihr lässt sich verhindern, dass unklare, nicht testbare oder betriebswirtschaftlich unsinnige Ideen in die Umsetzung geraten. Die in diesen Fällen unausweichlichen (und oft unschönen) Diskussionen können so unterbunden werden noch bevor es einen Anlass für sie gibt. Das Team kann sich stattdessen auf seine eigentliche, wertschöpfende Arbeit konzentrieren.
Für viele überraschend: trotz dieser Vorzüge ist die Definition of Ready kein offizieller Teil von Scrum sondern gehört zu den vielen good Practices, die man zwar befolgen, genau so gut aber auch weglassen kann. Da sie weit verbreitet ist kann das nicht an fehlender Bekanntheit liegen sondern ist von Schwaber und Sutherland bewusst beabsichtigt worden. Warum das?
Das mit der DoR verbundene Risiko ist, dass Teams sich dadurch versehentlich Wasserfall-artige Strukturen aufbauen können. Ein zu restriktives Beharren auf von allen Teammitgliedern verstandene Anforderungen wird zwangsläufig einen solchen Beschreibungsumfang zur Folge haben, dass wieder eine vorgelagerte Konzeptionsphase entsteht in der Detailspezifikationen erzeugt werden. Das wäre nicht mehr im ursprünglichen Sinn der Agilität.
Darüber hinaus ist eine zu detaillierte Definition of Ready ein Indikator für gleich zwei Antipattern: für unzureichende Backlog Refinements und für ein Misstrauen eines Entwicklungsteams gegenüber seinem Product Owner. Würden zur Umsetzung vorgesehene Anforderungen ausreichend besprochen (nicht beschrieben!) und würde das Team darauf vertrauen, vom PO nur umsetzbare Aufgaben zu erhalten - ein zusätzliches Quality Gate wäre unnötig.
Eine DoR ist aus diesen Gründen ein zweischneidiges Schwert. Sie kann unerfahrenen Teams bei der Umsetzung von Scrum helfen, kann aber auch versehentlich dazu führen, dass die Methodik sich selber aushebelt. Von vielen Teams wird sie daher gar nicht erst eingeführt oder irgendwann wieder abgeschafft.
