Ziele des Refinement-Meetings
Das Refinement Meeting (oder backlog grooming) ist in der SCRUM Literatur nicht als elementarer Bestandteil verankert hat aber durchaus seine Berechtigung. Es dient in erster Linie dazu, dass der Product Owner dem Team die neuesten User Stories erläutert. Durch eine gemeinsame Diskussion werden die User Stories hinterfragt und ausgearbeitet.
Die wesentlichen Gründe für das Refinement Meeting in SCRUM lassen sich wie folgt zusammenfassen:
- Verkürzung des Planungsmeetings
- Berücksichtigung neuester Informationen
- Komplexitätseinschätzung des Teams
Was passiert im Refinement Meeting?
- Diskussion der User Stories um Klarheit zu schaffen (nur das „was“ wird hinterfragt und nicht das „wie“)
- Aufteilung von User Stories die hoch priorisiert aber zu groß für den folgenden Sprint sind
- Zusammenlegung von User Stories falls sie zu klein ausfallen
- Diskussion der Akzeptanzkriterien, Annahmen und Einschränkungen
- Identifikation von Abhängigkeiten
- Schätzung
- Erstellung neuer User Stories aufgrund neuester Erkenntnisse
- Korrektur von Schätzungen aufgrund neuer Erfahrungen
Grundregeln für das Refinement Meeting
- Zeitliche Begrenzung (time-boxed) für jede User Story
- Definition der User Story nach dem INVEST Ansatz (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- Jeder arbeitet zusammen – Workshop
- Nicht „über diskutieren“ oder „über designen“
Beschreibung und Vorgehen
Der Product Owner stellt den Epic mit den zugehörigen User Stories vor. Empfehlenswert ist es, die User Stories ausgedruckt an die Wand zu hängen anstelle von digitalen Methoden. Das Team prüft, ob die User Story sinnvoll und umfassend beschrieben ist. Nun wird gemeinsam mit dem Team die Akzeptanzkriterien für die User Story definiert und festgehalten. Erst, wenn alle Teammitglieder einig über die Vollständigkeit der User Story sind, wird die Story mit Storypoints gemäß der Komplexität geschätzt.
Es ist nicht das Ziel hierbei den Aufwand im Sinne von Zeit zu schätzen. Die Storypoints geben später im Sprint zwar die Velocity wieder aber noch viel wichtiger, sind Differenzen in der Schätzung. Erst hierdurch wird klar, dass eventuell zwei Teammitglieder unterschiedliche Vorstellungen von der Umsetzung haben. Deshalb ist es wichtig, dass alle Teammitglieder mit schätzen, auch wenn sie gegebenenfalls nicht die Qualifikationen für die Umsetzungen besitzen und die Schätzkarten zeitgleich hochheben. Das Teammitglied mit dem höchsten Wert diskutiert mit demjenigen mit dem geringsten Wert. Hierdurch werden oftmals noch Verständnislücken oder auch verschiedene Umsetzungsansätze aufgedeckt. Anschließend wird erneut geschätzt und der Wert festgelegt. Sollten die Werte bereits bei der ersten Schätzung sehr nah beieinander liegen, kann eine zweite Schätzrunde entfallen.
Teilnehmer
Input
- Priorisierte und vorbereitete User Stories
Output
- Mit Komplexitätspunkten (Story-Points) versehene User Stories
- Gemeinsames Verständnis des Umsetzungsumfanges der User Stories
- Für jede User Story individuell festgelegte Akzeptanzkriterien
Frequenz und Dauer
- Wöchentlich
- ca. 1 Stunde
Owner
- Product Owner
Tipps für ein erfolgreiches Refinement Meeting
Häufigkeit
- Bewährt hat sich eine wöchentliche Durchführung des Refinement Meetings. Allerdings ist es auch nicht ratsam, zwischen dem Refinement Meeting und der Umsetzung zu viel Zeit verstreichen zu lassen. Als Daumenregel kann man sich merken: Man sollte User Stories für ca. 2 Sprints im Refinement Meeting besprochen haben.
Akzeptanzkriterien
- Die Akzeptanzkriterien gemeinsam im Team zu entwickeln hat sich als äußerst wirksam herausgestellt. Sind diese bereits vorneweg durch den Product Owner verfasst, führt dies dazu, dass das Team sich hierüber weniger Gedanken macht und somit Lücken bei der Abnahme entstehen.
Schätzmarathon
- Das Refinement Meeting darf nicht den reinen Fokus auf die Schätzung der User Stories haben. Dies ist nur ein kleiner Bestandteil des Meetings. Vielmehr geht es darum die Anforderungen zu diskutieren und die Komplexität einzuschätzen.
Digitalisierung
- Das reine Arbeiten mit JIRA oder einem anderen digitalen Board ist im Refinement Meeting nicht empfehlenswert. Die zu diskutierenden User Stories auszudrucken oder an ein Board zu schreiben und dort diese gemeinsam zu erarbeiten schafft höhere Transparent und Übersichtlichkeit.
Vorbereitung
- Der Product Owner muss das Meeting gut vorbereiten. Die wichtigsten anstehenden Stories des Backlogs müssen priorisiert, klar verständlich und klein genug beschrieben sein (INVEST)
Goal-Keeper
- Der SCRUM Master muss schauen, dass Diskussionen dem Ziel dienen, User Stories zu definieren und auszuarbeiten. Ausschweifende eben nicht diesem Ziel dienliche Diskussionen sollten unterbunden werden.