Ist die Definition of Ready noch sinnvoll?

​Die Definition of Ready

Die Definition of Ready gibt an, ab wann ein Product Backlog Item in das Sprint Planning gelangen darf. Dabei ist diese Vereinbarung zwischen dem Product Owner und dem Entwicklungsteam getroffen. Stellen wir uns diese Vereinbarung einfach als Checkliste vor, ähnlich wie auch die Definition of Done eine solche Checkliste repräsentiert.

​Was steht in der Definition of Ready?

Definition of Ready

In dieser Definition of Ready könnte stehen, dass alle Einträge klein genug sein müssen, damit sie in den Sprint aufgenommen werden dürfen. Hier könnte auch enthalten sein, dass alle Product Backlog Einträge (PBIs) einmal in einem Refinement gewesen sein müssen bevor sie in den Sprint gelangen können. Je nach Rahmenbedingungen oder auch der Branche in der das Team arbeitet, könnten auch benötigte Unterlagen wie Mock-Up's dort zu finden sein.

Kurz um, alles das, was das Entwicklungsteam benötigt, um an dem entsprechenden PBI arbeiten zu können, ist in dieser Definition of Ready enthalten.

​Definition of Ready im Scrum Guide? Fehlanzeige!

​Wer sich den Scrum Guide genauer ansieht stellt schnell fest, das dort keine Definition of Ready enthalten ist. Warum ist das so? Ist die Definition of Ready vielleicht einfach vergessen worden? Ich denke nicht und ​dafür gibt es einen sehr guten Grund.

​Ich habe allerdings selbst lange mit dieser Vereinbarung gearbeitet. Das Ergebnis war rückblickend nicht so hilfreich, wie zunächst gedacht. ​Auf einige dieser Aspekte meiner Erfahrung gehe ich genauer ein.

​Betrachten wir dazu das Ziel einer Definition of Ready. Wenn ein PBI in den Sprint aufgenommen werden kann, dann ist das ​Product Backlog Item auch ready, denn das Entwicklungsteam kann damit arbeiten. Wenn das PBI nicht fertig ist, dann kann das Entwicklungsteam folglicherweise nicht damit arbeiten. Also lautet das Ziel einer Definition of Ready, dem PBI zu bestätigen,  "jawohl du bist weit genug ausgearbeitet, du darfst in den Sprint!"

​Die Definition of Ready ist das Refinement!

​Die Aussage, ob ein PBI in den Sprint darf oder nicht wird im Refinement getroffen (und das finden wir auch wieder im Scrum Guide). Das Entwicklungsteam und der Product Owner arbeiten so lange an den Einträgen, bis sie:

Backlog Refinement Toolbox
  • ​klein genug
  • ​abgeschätzt und
  • ​mit Akzeptanzkriterien

versehen sind. Wenn damit alle Beteiligten das gleiche Verständnis haben, dann ist das Product Backlog Item reif genug und darf damit in den Sprint Einzug halten (wenn es das Team basierend auf der Priorität des Backlogs auch zieht).

​Dadurch wird ein PBI so lange verfeinert, bis es automatisch in den nächsten Sprint kann. Wenn ein Team zum Beispiel nicht in der Lage ist ein solches Product Backlog Item abzuschätzen, dann kann es auch nicht fertig sein. Damit ist das Ziel auch nicht erreicht, dass das Backlog Item in den nächsten Sprint kann.

​Formalitäten hin oder her

Versuchen Sie zunächst nicht die Definition of Ready in den Vordergrund zustellen. Etablieren Sie eine gute Kommunikation im Sinne der Scrum Events über die Product Backlog Einträge und führen Sie diese so zu einer Reife die es erlaubt, die Product Backlog Items in den nächsten Sprint zu nehmen.

Wenn es zwischen dem Entwicklungsteam und dem Product Owner Spannungen gibt, dann finden sich häufiger Definition of Ready's - so meine Erfahrung. Wenn die Entwicklungsteams und der Product Owner ein gutes Verhältnis haben, dann gibt es entweder auch eine Definition of Ready, die eher im Sinne einer Checkliste ("haben wir denn auch an alles gedacht?") genutzt wird und nicht als hartes Entscheidungskriterium. Oder es gibt sie eben gar nicht mehr, die Definition of Ready.

Grundsätzlich mein Tipp: genau der Argumentation bei dem Wunsch der Definition of Ready zuzuhören. Es kann durchaus ein Zeichen dafür sein, dass es Probleme in den Teams gibt. Im vierten Prinzip des agilen Manifest finden wir die Aussage:

Fachexperten und Entwickler
müssen während des Projektes
täglich zusammenarbeiten.

Wenn Sie eine Definition of Ready brauchen, prüfen Sie doch einmal, wie gut Sie dieses Prinzip aus dem agilen Manifest umgesetzt haben. Ist es hier vielleicht auch so, dass zu wenig Zusammenarbeit zwischen den Parteien erfolgt?

​User Stories und die Definition of Ready

Zu guter Letzt: Es gibt immer Rahmenbedingungen, die dazu führen können, dass eine Definition of Ready sinnvoll ist. Oft mag es auch helfen, dort gewisse Standards als Erinnerungen abzulegen. Was es nicht sein darf und nicht soll: ein Ersatz für die oben genannte Kommunikation zwischen den Fachexperten und Entwicklern.

Bei meinen ganzen Betrachtungen bin ich davon ausgegangen, dass wir User Stories benutzen. Das müssen Sie natürlich nicht tun und können auch andere Notationsformen verwenden. Eine User Story ist nicht Teil des Scrum Guides und nicht verpflichtend für Scrum. Bei der Benutzung von User Stories wollen wir uns allerdings daran erinnern, dass diese keine Requirementsartefakte sind. Mike Cohn hat es in seinem (englischsprachigen) Blogposting einmal sehr treffend und schön formuliert.​

Viele Publikationen die auf die Definition auf Ready eingehen, bewerten diese oft anhand von Kriterien des IEEE Standards im Bereich von Qualität und Anforderungen. Das können Sie natürlich tun, dann dürfen Sie sich aber nicht auf User Stories beziehen, denn genau dieses ​Kommunikationsversprechens​ ist ja genau kein Requirementsartefakt.

User Stories sollten dem INVEST Prinzip folgen, das bedeutet sie sollen unabhängig (independent) von einander sein, verhandelbar (negotiable) bleiben, einen (Mehr)wert haben (valuable), abschätzbar (estimatable) sein, die richtige Größe (size) besitzen und ebenso auch testbar (testable) sein. Das eignet sich bestens als Vorlage und kann dann bei nicht erreichen in der Retrospektive genutzt werden, um zu reflektieren.

​Definition of Ready vs. Definition of Done

Definition of Ready
  • check
    ​Einhaltung durch den Product Owner
  • check
    ​Bestimmt wann ein PBI in den Sprint darf
  • check
    ​Liste von Kriterien
Definition of Done
  • check
    ​Einhaltung durch das Team
  • check
    ​Bestimmt wann ein PBI fertig ist
  • check
    ​Liste von Kriterien

​Definition of Ready beschreibt keine Anforderungen an Requirements

​Zum Schluss möchte ich die Wichtigkeit adressieren genau auf den Inhalt des Product Backlogs zu schauen. Wenn dort User Stories enthalten sind und auch diese so genutzt werden, wie es gedacht ist, dann kann die Definition of Ready in meinen Augen in vielen Situationen weggelassen werden.


Wenn Sie allerdings eine "andere Art" von Product Backlog Items führen, dann kann es durchaus der Fall sein, dass Sie die Definition of Ready sinnvoll und ​vielleicht sogar absolut nötig sein.

Leave a Reply 0 comments

Leave a Reply:







>

Scrum Newsletter: Vorlagen | Tipps | Praxis