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

Rezept eines Sprint Plannings (SP 1)

Sprint Plannings (SP) kann man auf viele verschiedene Arten durchführen. Ich persönlich bevorzuge ein Sprint Planning 1 und 2, aufgetrennt mit Fokus auf das WAS (SP 1) und das WIE (SP 2).

Das Planning 1 nutzen wir um den Ablauf der zu besprechenden Items zu diskutieren. Hier gehe ich davon aus, dass das Refinement stattgefunden hat, der grobe Plan für den nächsten Sprint bereits bekannt ist und die Items trotzdem noch nicht bis ins letzte Detail besprochen sind (um Verschwendung vorab zu minimieren).

Bild von Stuart, "Checklists that matter" (Creative Commons 2.0), Flickr

Bild von Stuart, "Checklists that matter" (Creative Commons 2.0), Flickr

Ziel und Zweck ist für mich somit das Festhalten des Umfangs für den nächsten Sprint. Das gilt für die Summe der Items als auch für den Umfang eines jeden Items. Zudem planen wir gemeinsam die Reihenfolge. Es ist sowohl ein kooperativer Prozess, das Beste aus den nächsten Wochen herauszubekommen, als auch das Briefing des Teams.

Zu einem guten Sprint Planning gehört für mich eine Vorbereitung, die keine Zeit der Teilnehmer verschwendet, und ein klarer, wiederkehrender Ablaufplan für das Planning selbst.

Ich beschränke mich in diesem Artikel auf die Vorbereitung und den Ablauf eines Sprint Planning 1.

Vorbereitung

  • Abschließen des Vorgänger-Sprints, evtl. Übertrag liegt priorisiert vor
  • Alle Items sind "ready", nach Definition of Ready: Items sind frei von Blockaden und Schlüsselfragen, geschätzt, klein, bekannt, etc.
  • Items liegen in priorisierter Liste vor
  • Verschicken der Einladungen für die Teilnehmer
  • Buchen der Räume inkl. Rüstzeiten
  • Einholen der Abwesenheiten (Team-Kalender + evtl. Stakeholder)
  • Vorbereiten der Besprechung (technische Vorbereitung beginnt circa. 20 Minuten vorher)

Materialien

Flipchart(s), Whiteboard(s), Beamer, Rechner, Post-Its (alle Items auf Post-Its vorbereitet), Stifte, Kamera

Optional: Remote-Ausstattung wie Video-Kamera(s), Mikrofon, WebEx oder ähnliches

Ablauf

Set und Setting (5min)

Ziel: Ermitteln der Kapazität des Sprints.

Lead: ScrumMaster

  • Checken der Anwesentheit
  • Aufnehmen der Verbesserungen der Retrospektive
  • Ermitteln/Abgleichen des Forecasts mittels Velocity Chart mit Kapazität

Setting the Stage (10min)

Ziel: Erzeugen des Gesamtbildes für alle Beteiligten und setzen des Fokus für den Sprint.

Lead: Product Owner

  • Sprintziel vorstellen
  • Übersicht über alle geplanten Themen geben

Vorstellen der Items (90 min)

Ziel: Verstehen der einzelnen Items und festlegen des Umfangs pro Item (ggf. Vereinfachen von Items).

Lead: Product Owner

  • Durchsprechen/-arbeiten eines jeden Items
  • Festhalten der Akzeptanzkritieren pro Item
  • Abgleichen mit Definition of Done

... solange bis die Zeit ausläuft oder ein Veto des Teams auftritt. Das Veto bzw. nächste Go kann mit einer Fist-of-Five oder einer Konsent-Abstimmung ermittelt werden.

Optional: Festhalten der Akzeptanzkriterien pro Item auf einem Flipchart.

Commitment und Negotiation (15 min)

Ziele: Überprüfen ob das Commitment sinnvoll und möglich ist und Strukturieren des logischen Aufbaus.

Lead: ScrumMaster

  • Absprache über Umfang inkl. Austausch von Items
  • Festlegen der Abarbeitungsfolge der Items
  • Checken der offenen Items zum Start (WIP-Limit für den Sprint setzen)

Ein Sprint Planning ist kein Dogma. Es sollte jedoch klar strukturiert und vorbereitet sein. Wenige Teams mögen es mit unbekannten Items konfrontiert zu werden. Noch unbeliebter sind Items, die nicht ausreichend vorbereitet und unvollständig sind. Hier verschwendet man Zeit, was wiederum mangelnden Respekt gegenüber dem Team ausdrückt.

Während eines Sprint Planning 1 nutze ich Forecast und Commitment. Der Forecast hilft dem Team den Umfang und die eigene Kapazität besser einzuschätzen. Das Commitment wird genutzt um den Pull-Effekt zu erzielen und Hoheit über die eigene Arbeitslast sicherzustellen.

SVNWNK