TopMenue

Refinement-Meeting

Dieser Beitrag befindet sich noch in Bearbeitung!

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

Aufgabe Vorplanung von Aufgaben, die in den als nächstes folgenden Sprints umgesetzt werden sollen
Organisator Product-Owner
Teilnehmer Entwicklungsteam, Scrum-Master, Product-Owner.
Optional: Stakeholder, weitere Gäste
Zeitpunkt Ca. zu Beginn des letzten 1/4 des Sprints
Dauer nicht länger als ca. 1/2 Tag

Beschreibung

Der Ablauf des Refinement-Meetings gestaltet sich ganz ähnlich wie der des Sprint-Planning Phase 1, da der Product-Owner mit der Durchführung der beiden Meetings ganz ähnlich Ziele verfolgt.

Der Product-Owner möchte
  1. die anwesenden Personen (Entwicklungsteam, Scrum-Master und eventuelle Gäste) über die in naher Zukunft kommenden Aufgaben informieren und
  2. vom Entwicklungsteam eine Aufwandsschätzung bzgl. der präsentierten User-Stories erhalten.

Wie viele Einträge er aus dem Product-Backlog für das Meeting vorsieht, macht er daran fest, wie viele User-Stories das Entwicklungsteam seiner Erfahrung nach im Zeitraum des Meetings (Timebox 4 Stunden) schätzen kann; auf jeden Fall verwendet er, wie auch im Sprint-Planning, die Product-Backlog-Items höchster Priorität.

[Refinement-Meeting]

Der Ablauf des Meetings gestaltet sich ganz ähnlich dem des Sprint-Planning:
  1. Präsentation der User-Stories durch den Product-Owner
  2. Diskussion und Schätzen der User-Stories durch das Entwicklungsteam

Im Gegensatz zum Sprint-Planning beziehen sich die vorgestellten User-Stories aber nicht auf den aktuellen Sprint und die Realisation beginnt auch nicht im direkten Anschluss an das Meeting. Daher ist es nicht notwendig, dass das Entwicklungsteam zum Abschluss des Meetings das Commitment (das Versprechen, die geschätzten User-Stories innerhalb des Sprints vollständig zu realisieren) abgibt, noch schließt sich eine 2. Phase zum Schneiden der User-Stories in Tasks an.

Spätestens jetzt wird die Frage gestellt, die an dieser Stelle immer gern zum Refinement-Meeting gestellt wird: „Was zum Teufel soll der ganze Quatsch? Es wird nur vorgestellt, es wird nur gequatscht, es wird nur geschätzt, niemand arbeitet, niemand ist produktiv, nichts geht voran, es ist unnütz, es ist doppelter Aufwand, im Sprint-Planning des nächsten Sprints wird das Gleiche quasi noch einmal gemacht … warum also dieses ganze, zeitfressende, unnütze Meeting?“
Unnützes Meeting?

Das Refinement-Meeting ist eines der am meisten unterschätzten Meetings in Scrum. Es ist oft das erste Opfer falsch verstandener „Optimierungsmaßnahmen“, weil es dem Sprint-Planning sehr ähnlich und zeitlich zum Ende des aktuellen Sprints durchgeführt wird und von daher offenbar überflüssig zu sein scheint.

Warum ist es denn nun doch nützlich?

Scrum ist eine Methodik, die sich stets darum bemüht, ineffiziente Strukturen effizienter zu gestalten, also Reibungsverluste zwischen den Akteuren zu vermeiden, bzw. zu minimieren, Kanten zu glätten, oder wie auch immer man es nennen will. Jeder, der sich schon mal mit dem Thema „grüne Welle“ im Straßenverkehr beschäftigt hat, kennt das Phänomen: man fährt vielleicht etwas langsamer, aber trotzdem schneller und sparsamer, weil man sich das Abbremsen und wieder Beschleunigen spart und auf einem relativ hohen Geschwindigkeitsniveau und „im Fluss“ bleibt.

Bei näherer Betrachtung stellt man fest, dass das ist hier auch der Fall ist. Der Nachschub an Informationen über das „Große und Ganze“ bricht nach dem Sprint-Planning für den Rest des Sprints nicht ein, sondern wird aufrecht erhalten, denn das Refinement-Meeting sorgt für einen kontinuierlichen Fluss und Austausch von Informationen bzgl. der zukünftigen Aufgaben zwischen Product-Owner und Entwicklungsteam, von dem alle Seiten profitieren.

Das Argument, es würde doppelter Aufwand betrieben, ist ebenfalls nicht stichhaltig, da das Refinement-Meeting als Vorbereitung des nächsten Sprint-Plannings zu sehen ist, das — auf diese Art und Weise vorbereitet — viel schneller ablaufen kann, da die Informationen in den Köpfen der Beteiligten bereits Zeit zum Reifen hatten.

Darüber hinaus bekommt der Product-Owner wertvolles Feedback und frühzeitige Informationen über zu erwartende Aufwände und kann neu bewerten, ob und welche Story ihm wirklich wichtig ist.

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE