Dieser Beitrag befindet sich noch in Bearbeitung!
| 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
- die anwesenden Personen (Entwicklungsteam, Scrum-Master und eventuelle Gäste) über die in naher Zukunft kommenden Aufgaben informieren und
- 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]](http://scrumcess.de/wp-content/uploads/2015/03/Refinement-Meeting.png)
Der Ablauf des Meetings gestaltet sich ganz ähnlich dem des Sprint-Planning:
- Präsentation der User-Stories durch den Product-Owner
- 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.
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.
No comments yet.