READY TO PLAY: Definition of Ready (DoR)

Um Blockaden während der Entwicklung zu minimieren, treffen Teams immer wieder gerne eine Vereinbarung bzgl. dem Stand von bearbeitungsfähigen Items - kurz Definition of Ready (DoR).

Die Definition of Ready umfasst alle Punkte, die abgeklärt sein müssen, damit die Entwicklung beginnen und durchgeführt werden kann. Hier geht es um Zulieferungen an das Team und Vorbereitungsmaßnahmen vom Team selbst. Optimalerweise nimmt man die Punkte auf, die Blockaden verursachen und die Entwicklung (deutlich) verlangsamen. Obwohl das zumeist kontextabhängig ist, gibt es einige Punkte, die Teams immer wieder stolpern lassen.

Deswegen ein Beispiel für eine Definition of Ready:

Pflicht:

  1. Das Item ist dem Team bekannt und es ist geschätzt
  2. Das Item ist klein genug, damit es in einem Sprint umgesetzt werden kann
    1. max. ein Fünftel der Velocity oder 1-5 Story Points
  3. Das Item ist frei von Blockaden
  4. Das Item ist frei von externen Abhängigkeiten
  5. Das Item ist testbar
    1. anhand der Kriterien und mit akzeptablen Aufwand
    2. in einer verfügbaren Umgebung != Dev-Rechner (z. B. bei Fremdsystem-Integration)
  6. Es liegen alle Dokumente, die zur Umsetzung benötigt werden vor (Designs, Bilder, mehrsprachige Texte, Schnittstellendokumentation) oder ist ein Ergebnis des Sprints und das Team ist befähigt das Ergebnis zu erbringen

Optional:

  1. Das Item ist verständlich beschrieben anhand von Akzeptanzkriterien
  2. Der Business-Wert für das Item ist klar artikuliert und messbar
  3. Technisches Restriktionen (Constraints) sind beschrieben, sofern vorhanden
  4. Relevanz für Stakeholder z. B. Datenschutz oder Security wurde geprüft und daraus resultierende Ansprüche sind aufgenommen (als eigene Stories oder Akzeptanzkriterien)

Thomas Hawk, "Ready", Creative Commons 2.0, Flickr

Die Definition of Ready sollte nicht als starres Dokument angesehen werden. Vielmehr können mit der Reife und zunehmender Cross-Funktionalität des Teams sich Punkte in den Aufgabenbereich des Teams verschieben. Dadurch wird das Team autonomer und bündelt mehr Arbeit im Team. Ob es dadurch langsamer oder schneller wird hängt von der Effektivität der vorigen und neuen Organisation ab. Skaliert eine solche Verschiebung nicht, kann es auch sein, dass weitere Punkte in die Definition of Ready aufgenommen werden müssen. Dabei erhöht man die Abhängigkeiten des Teams von externen Quellen.

Persönlich tendiere ich dazu die Autonomie eines Teams zu stärken. Das liegt daran, dass ich die Erfahrung gemacht habe, dass die Anzahl der Blockaden und Wartezeiten deutlich sinkt und mit mehr umspannenden Aufgaben ein Team ein besseres Verständnis für die Fachdomäne entwickelt. Nicht zuletzt schätzen viele Teams es, eine ganzheitliche Lösung zu liefern. Zusätzlich nimmt das Konfliktpotential zwischen Teams und Organisation an den Schnittstellen ab.

Auch wenn in Ausnahmefällen auf einzelne Punkte verzichtet werden könnte, so sollte man den Prozess nicht aufweichen. Wenn man das macht, dann degeneriert man leicht den Entwicklungsprozess und landet im öden Mittelmaß der eigenen Leistungsfähigkeit bzw. öffnet der Disziplinlosigkeit Tür und Tor (broken window principle).

Letztlich muss das Team entscheiden, ob ein Item sinnvoll bearbeitungsfähig ist. Ist ein Item das nicht und besteht wer auch immer auf die Bearbeitung, so trägt diese Person die Verantwortung für die unwirtschaftlichen Konsequenzen in Zeit, Budget und Anwenderzufriedenheit.

SVNWNK