Die traurige Wahrheit, es gibt sie wirklich – die „Definition of Ready“. Es ist eine Sammlung an kurzen Punkten, welche beschreiben, welchen Zustand eine User Story haben muss, bevor sie in einen kommenden Sprint geplant werden kann.
Soweit klingt das vollkommen in Ordnung. Eine klassische DoR sieht daher wie folgt aus:
- Die Story muss im Format „Als <Benutzer> möchte ich <Funktion> damit <Mehrwert>“ beschrieben sein
- Die Story muss von jedem Teammitglied verstanden werden
- Akzeptanzkriterien sind erfasst
- Testkriterien sind bekannt
- Performancekriterien sind bekannt
- Es ist bekannt wie das Ergebnis demonstriert werden kann
- Story ist geschätzt
Nun neigen viele Projektteams dazu diese Definition zu erweitern. So findet sich dann häufig folgende DoR wieder:
- Die Story muss im Format „Als <Benutzer> möchte ich <Funktion> damit <Mehrwert>“ beschrieben sein (falls es nicht anders geht)
- Die Story muss verstanden werden
- Akzeptanzkriterien sind klar definiert und umsetzbar
- Testkriterien sind bekannt (geht leider nicht immer)
- Performancekriterien sind bekannt (müssen wir noch klären)
- Es ist bekannt wie das Ergebnis demonstriert werden kann
- Story ist geschätzt (StoryPoints)
- Ressourcen sind verfügbar und einsatzbereit
- Story ist analysiert
- Story ist klein genug für einen Sprint
- etc.
Nun haben wir den Salat. Die Diskussionen, ob die DoR nun wirklich auf jede Story im Sprint angewendet werden kann – jeder kennt sie.
Doch warum kommt es nun dazu?
Häufig wird die Definition of Ready (und eigentlich so ziemlich jedes Artefakt im agilen Umfeld) als Vertrag behandelt. Bei der DoR einem Vertrag zwischen Entwicklungsteam und Product Owner. Hält man sich nicht an die DoR wird entweder der PO oder das Team an die Wand gestellt.
Die DoR (und jedes andere Artefakt im agilen Umfeld) sind jedoch Hilfsmittel. Nicht mehr und nicht weniger. Das bedeutet: der klare Verstand, die Experten und die Stakeholder arbeiten wohlwollend für das gleiche Ziel. Die DoR unterstützt dabei, einige Punkte zu hinterfragen und so zu einem Informationsfluss zu kommen. Mitnichten ist es ein Vertrag, im entferntesten Sinne könnte man es als Absichtserklärung benennen – aber es ist ein „Talk maker“ – über wichtige Dinge sprechen und Entscheidungen gemeinschaftlich treffen.
Die Story kann nicht im angegebenen Format beschrieben werden? Gut, dass wir darüber gesprochen haben. Akzeptanzkriterien benötigen wir nicht? Schön, dass wir uns über die Beschreibung einig sind. Performancekriterien benötigen wir für den Service nicht? Traumhaft, wir haben intensiv darüber nachgedacht!