Als Requirements Engineer und Business Analyst ist es unser Kollege Andreas gewohnt, sich durch seitenweise Dokumente zu wühlen. Was er bei der Vorbereitung zu einer Scrum.org-Prüfung aus dem Scrum-Guide herausgelesen hat – oder besser gesagt, „nicht herausgelesen” hat, lest ihr im folgenden Blogbeitrag.
Den Begriff DoR (definition of ready) verwendet der Scrum Guide in seiner aktuellsten Version (11/2020) überhaupt nicht (mehr).
Funfact #1: „Definition of Done” taucht dafür aber 16 Mal auf.
Im Kapitel „Scrum Artifacts: Product Backlog” taucht die Bezeichnung:
„… bereit für die Auswahl (in einem Sprint-Planning-Event)”
auf. Im Kapitel „Scrum Events: Sprint Planning” steht im Scrum Guide:
„… Der:die Product Owner:in stellt sicher,
- dass die Teilnehmenden vorbereitet sind,
- die wichtigsten Product-Backlog-Einträge zu besprechen,
- und wie sie dem Produkt-Ziel zuzuordnen sind. “.
Moment, weshalb ist die DoR im Scrum Guide nicht (mehr) erwähnt?
Zunächst ein Wenig Archäologie:
- 1. Aktualisierung = 2. Auflage / Version des Scrum Guides, 2011: das Wort „ready” (in Anführungszeichen) wird in den Scrum Guide aufgenommen, im gleichen Satz wie „Done” und ist ab da eine Regel in Scrum.
- 4. Aktualisierung = 5. Version des Scrum Guides, 2013: der „Done” und „Ready” betreffende Satz wird umformuliert und nachgeschärft. „Ready” erhält die Gleiche Bedeutung wie „Done”.
- 6. Aktualisierung = 7. Version des Scrum Guides, 2020: der „Done” und „Ready” enthaltende Satz wird erneut umformuliert und “Ready” entschärft.
Entschärft bedeutet in diesem Zusammenhang, dass „Ready” nun keine Regel mehr ist und es dadurch der Scrum Guide dem Team selbst überlässt, eine DoR zu verwenden. Der Scrum Guide möchte durch seine letzten Aktualisierungen weniger restriktiv sein und mehr Freiheiten zum Selbstmanagement enthalten. Deshalb erlaubt er dem selbst gemanagten Scrum Team also – ermutigt es sogar – sich eigene Standards und „Quality Gates” zu etablieren.
Ok, was genau ist eine „definition of ready”? Und wann genau ist ein Product-Backlog-Eintrag „bereit für die Auswahl”?
Die „Scrum Inc.” (ein Beratungsdienstleister und Trainingsanbieter; gegründet von Dr. Jeff Sutherland, einem der beiden Urheber von Scrum), beschreibt diese als:
„… Eine Definition of Ready bedeutet, dass (User-)Stories sofort umsetzbar sein müssen. Das Team muss in der Lage sein, zu bestimmen, was getan werden muss und wie viel Arbeit erforderlich ist, um die User Story oder PBI fertigzustellen. …”
Der Scrum Guide sagt hierzu
„… Product-Backlog-Einträge, die
- durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten.”
Es geht also darum, dass ein Product Backlog Item (PBI) im Scrumteam „genügend gut” besprochen und analysiert wurde und ein gewisser „Transparenzgrad” erreicht ist. Maßnahmen zur Erreichung dieses Stadiums können bspw. inhaltliche und technische Klärungen, sowie „schneiden” sein (d. h. Verkleinern durch Aufteilen).
Funfact #2: Im Sinne des Scrum Guides – entgegen der etablierten agilen Praxis – stellen Refinement-Aktivitäten übrigens keinen eigenen Scrum-Event /-Termin („Backlog Refinement”) dar, sondern eine „fortlaufende Aktivität” des gesamten Scrum Teams, also des Dev-Teams in Kollaboration mit dem / der PO.
Gleiches gilt natürlich für die Erstellung und Beachtung einer evtl. DoR – hier ist ebenfalls das gesamte Scrum-Team am Zug.
Wie beschrieben, steht es dem selbst gemanagten Scrum Team frei, sich eine DoR zu überlegen und mit dieser zu arbeiten. Im Sinne des agilen Mindsets empfiehlt es sich, mit einer evtl. ersten Version / Draft einer DoR in den ersten Sprint zu starten und diese dann regelmäßig, d. h. bei Retrospektiven, zu überprüfen und ggf. anzupassen. In der scrum.org-Community herrscht die Auffassung, die DoR sollte mehr eine „Guideline” (Richtschnur) sein, anstelle eines echten „Stage-Gates” (Trittschwelle).
Relevant wird dieser „Reifegrad” bzw. eine evtl. DoR dann beim Sprint-Planning-Event – denn spätestens hier sollten alle selektierten Produkt-Backlog-Einträge bereit zur Umsetzung sein und (falls vorhanden) alle erforderlichen „Quality Gates” bereits durchlaufen haben.
Abschließend ein „Quality Gift” für die Leser, die bis hierhin durchgehalten haben: die QM-DoR-Checkliste (ja – INVEST für eine User-Story ist gleichzeitig schon eine DoR):
Der Buchstabe… | … steht für | Für eine DoR bedeutet das… |
---|---|---|
I | independent |
|
N | negotiable |
|
V | valuable |
|
E | estimatable / estimated |
|
S | small |
|
T | testable |
|
…and now it´s up to you!
Verwendet euer Team eine DoR? Wenn ja, wie sieht diese aus?
Was sind euere Erfahrungen mit der DoR? Schreibt uns eine Mail: hello@qualityminds.de
* Link zur “helpful artifact map”: https://qualityminds.com/wp-content/uploads/2021/11/Sonderdruck_OS_3_2019_Qualityminds-Digital.pdf
0 Kommentare