Das Product Backlog Refinement ist eines der wichtigsten Meetings im SCRUM-Kontext. Hier werden diejenigen Product Backlog Items besprochen, die mit hoher Wahrscheinlichkeit Teil des nächsten oder übernächsten Sprint Backlogs werden.
Der Termin ist eine Zusammenarbeit des gesamten SCRUM Teams und stellt vor dem Hintergrund der Remote-Arbeit besondere Anforderungen an die Teilnehmer.
Product Owner
Die Zusammenarbeit mit remote arbeitenden Teammitgliedern oder gegebenenfalls sogar vollständigen remote Teams, stellt den Product Owner vor eine große Herausforderung.
Von ihm wird erwartet, dass er in einem möglichst kompakten Termin, am besten für alle relevanten Stories gleichzeitig, folgende Fragen des Teams zu beantworten kann:
Welche Probleme hat der Kunde aktuell mit dem Produkt?
Hier gibt es oft qualifiziertes Feedback von Kunden, das dem Dev-Team auch oft selbst schon vorliegt. Hier reicht es, das aufgetretene Problem nachzustellen. In den meisten Fällen resultiert aus dieser Diskussion ein Bug-Ticket, das die Behebung des Problems beschreibt.
Für den Fall, dass das Problem nicht nachgestellt werden kann, wird oft ein Analyse-Ticket erstellt, um das Problem nachzustellen.
Hierfür reicht es, wenn der Product Owner das Feedback vorliegen hat und im Rahmen von Screensharing mit dem Team teilt. Im geteilten Bildschirm kann dann die Beschreibung und auch das erstellte Ticket angezeigt und diskutiert werden.
Welche zusätzlichen Mehrwerte können dem Kunden mit dem vorliegenden Produkt geschaffen werden?
Hier geht es um neue Funktionalität. Wenn der Product Owner entscheidet, Product Backlog Items zu besprechen, die dem Produkt neue Funktionalität verleihen sollen, ist es besonders wichtig, dem Team einen Überblick zu geben. Hier sollte dem Team – vor der Vorstellung der konkreten Backlog-Items – erklärt werden, welcher Bereich des Produkts zur Diskussion steht, welche übergeordnete Funktionalität am Ende das Produkt erweitern soll und, wie das ganze zur Produkt-Vision passt.
Wie der Product Owner das macht, hängt von der Art des Produkts ab:
- Frontend Software: Hier hat es sich bewährt, das Produkt zu öffnen und in einem geteilten Bildschirm den aktuellen Stand oder Startpunkt der neuen Funktionalität zu zeigen. Ab dann können schematische Darstellungen, eine PowerPoint oder ggf. Schon existierende Mock-Ups als Diskussionsgrundlage dienen.
- Backend Software: Da die Funktionsweise von Backendprodukten nicht direkt visuell darstellbar ist, gibt es für diese oft Entscheidungsbäume oder Flowcharts. Im Rahmen der Mehrwertvorstellung von Product Backlog Items, bietet es sich an, diese als Erklärungsgrundlage zu verwenden und einen Vergleich „vor und nach der intendierten Produktverbesserung“ durchzuführen.
- Andere Produkte: Für andere Produkte sollte der Product Owner mit Hilfe seiner persönlichen Erfahrung das Medium wählen, das er nutzen möchte. Sollte etwas hardwarebasiertes gezeigt werden, sollte er auf Video-Übertragung setzen oder ein Video im Vorhinein vorbereiten und mit dem Team teilen.
In allen Fällen reicht es, dass der Product Owner mit dem restlichen SCRUM Team in einer Telefonkonferenz ist, in der er den Kollegen seinen Bildschirm teilen und die Gedanken zu den Product Backlog Items erläutern kann. Videos können so ebenfalls geteilt werden und man ist auch für den zweiten Schritt, wo das gesamte Team zusammenarbeitet, gut vorbereitet.
Einen Artikel, wie man ein Online Meeting gut vorbereitet, findet sich hier.
SCRUM Team
Nachdem der Product Owner den Überblick gegeben hat und das „Was machen wir“ und auch das „Warum machen wir es“ erläutert oder geklärt hat, hat das Team ggf. Rückfragen an den Product Owner.
Sobald die geklärt sind, ist es die Aufgabe des gesamten SCRUM Teams, die Product Backlog Items soweit vorzubereiten, dass sie im nächsten Sprint Planning in das Sprint Backlog aufgenommen werden könnten.
Dazu gehören:
- Ergänzung der Item Beschreibung
- Die Unterlagen des Product Owners zur Vorstellung
- Technische Details, das „Wie machen wir es“
- Aufteilung des Backlog Items in Subtasks
- Schätzung
- ggf. Prototypisches Design, design Mockups, REST interfaces, Datenstrukturen und Ähnliches
Um diese ganzen Themen abdecken zu können, braucht es weiterhin einen Moderator, dessen Bildschirm für das SCRUM Team geteilt bleibt, sodass die Punkte gemeinsam diskutiert werden können. Da der Product Owner mit der Vorstellung der Backlog Items begonnen hat, bietet es sich an, dass er die Moderation des Termins fortführt.
Alternativ kann ein anderes Teammitglied übernehmen, falls beispielsweise für Mockups ein bestimmtes Tool genutzt werden soll.
Eine Herausforderung im Rahmen des Refinements ist dann schließlich das Tool zur Schätzung der Backlog Items. Die Teammitglieder sollten sich nicht untereinander beeinflussen können, aber trotzdem auf dem gleichen inhaltlichen Stand bleiben. Hier hat sich in meinem Team PlanITpoker.com am besten bewährt.
Zusammenfassung
- Der Product Owner sollte im Refinement vorbereitet sein, neue gewünschte Funktionalitäten zu zeigen und in den korrekten Kontext zu setzen.
- Für das Product Backlog Refinement reicht eine Online Konferenzlösung mit der Möglichkeit, dass ein Referent seinen Bildschirm teilt (Wie führe ich engaging Online Konferenzen durch?)
- Für Schätzungen im Rahmen von Planning Poker, kann man PlanITpoker.com verwenden
- Auch online gilt: „Ein Backlog Refinement sollte so gut und umfangreich sein, dass der PO nicht vom Ergebnis der Entwicklung überrascht ist“
Leave a Comment