Definition of Ready

Dienstag, 1. Januar 2019
Dieser Blogartikel beschreibt den Agilen Baustein Definition of Ready.

Die Definition of Ready (kurz DoR) beschreibt, welche Qualitätskriterien von Produktanforderungen (z.B. User Stories, Features o.ä.) erfüllt sein müssen, damit diese „ready“ sind und vom Entwicklungsteam für die Umsetzung angenommen werden. Sind sie nicht erfüllt stoppt die Weiterarbeit, da die nötigen Eingangsbedingungen offensichtlich nicht erfüllt sind. Für Jeff Sutherland ist „ready“ gleichbedeutend mit „Ah, we get it“. Durch eine klare Definition der wichtigsten Kriterien wird sichergestellt, dass die eingehenden Anforderungen alle für die Umsetzung nötigen Informationen enthalten und vom Entwicklerteam ohne weitere Nachfragen umgesetzt werden können. In der Regel ist eine Person für die Einhaltung der vereinbarten Kriterien verantwortlich, in Scrum ist dies der Product Owner.

Beispiele für Punkte einer Definition of Ready können sein:

  • Anforderungen sind geschätzt.
  • Anforderungen haben einen Business-Value.
  • Anforderungen sind klein genug für die Bearbeitung im nächsten Sprint.
  • Akzeptanzkriterien sind für jede Anforderung definiert und testbar.
  • Anforderungen sind für alle Beteiligten klar verständlich

Ziele

  • Kundenmitsprache
  • Mitarbeitermotivation
  • Dokumentation
  • Testbarkeit / Anhamekriterien

Vorteile

Die DoR bewirkt anhand ihrer strikten Kriterien eine höhere Eingangs-Qualität der Anforderungen. Die DoR unterstützt ein höheres Systemverständnis bei allen Beteiligten. Da vorgegeben wird, welche Informationen vom Team benötigt werden, bevor mit der Umsetzungsarbeit begonnen wird, kann Dokumentationsaufwand eingespart werden. Die DoR kann gleichzeitig als Vertrag zwischen dem Entwicklerteam und dem Produktverantwortlichen gesehen werden. Durch die klare Angabe der Erwartungen wird sichergestellt, dass der Produktverantwortliche seinen Aufgaben nachkommt, Konflikte reduziert werden und die Zusammenarbeit verbessert wird.

Anwendung

Vorbedingungen

Es muss eine klare Aufteilung in Arbeitseinheiten (z.B. User Stories, Features, Epics etc.) erfolgt sein, um für diese Arbeitseinheiten konkrete Kriterien für die DoR festzulegen.

Nachbedingungen

Die DoR selbst ist (seiten-) effektfrei, d.h. kein Arbeitsergebnis wird in irgendeiner Weise geändert. Alle in der Entwicklung eingehenden Anforderungen entsprechen einheitlich vorher definierten Kriterien.

Variationsparameter

Es gibt Freiheitsgrade hinsichtlich des Weglassens / Verwendens von bestimmten Kriterien für bestimmte Ergebnisteile.

Fallstricke

Eine überdimensionierte Liste mit Kriterien kann kontraproduktiv sein und schnell wieder zurück zu traditionellen Anforderungsdokumenten führen. Das Ausmaß der Liste sollte deshalb auf das Minimum der erforderlichen Kriterien reduziert werden, um die Anforderung in „ready“ zu überführen. Die Bewertung, ob eine Anforderung der DoR entspricht, sollte vom Team getroffen werden, nicht vom Produktverantwortlichen. Eine DoR ist nach einmaliger Definition nicht komplett, sondern muss immer wieder geprüft und angepasst werden, da ansonsten Verbesserungspotenzial übersehen wird.