Product Backlog Refinement
Laut dem Scrum Guide ergänzt das Product Backlog Refinement den Product Backlog; Einzelheiten werden ergänzt, Einschätzungen getroffen und der Product Backlog wird geordnet. Jedoch ist nirgendwo eindeutig angegeben, wie das Product Backlog Refinement erfolgen sollte. Daher hat das Scrum-Team zu bestimmen, wie und wann dies geschieht.
Ermittlung von Abhängigkeiten
Eines der Ziele bei der Erstellung eines Product Backlog Refinement ist die Ermittlung von Abhängigkeiten. Dabei handelt es sich beispielsweise um Abhängigkeiten zwischen einzelnen User Stories oder im Entwicklungsteam fehlen die nötigen Leute, wodurch es von anderen Personen abhängig ist, die nicht zum Team gehören. Weil dieser Prozess frühzeitig erfolgt, können diese Dinge gelöst werden, bevor sie zu Problemen führen.
So kann ein Product Owner beschließen, eine User Story anders zu formulieren, damit sie nicht mehr von einer anderen User Story abhängig ist, sondern eine eigenständige Aufgabe darstellt.
Einschätzungen
Ein anderes Ziel, das mit der Erstellung eines Product Backlog Refinement verfolgt wird, ist die Vervollständigung von User Stories durch die Einfügung von Einzelheiten. In einer früheren Phase des Arbeitsprozesses schrieb der Product Owner diese kurze Aufgabenbeschreibung in den Product Backlog. Durch die ergänzten Einzelheiten kann das Entwicklungsteam leichter einschätzen, wie viel Zeit für die Bearbeitung einer User Story genau benötigt wird.
Richtige Einschätzungen sind sowohl für den Product Owner als auch für das Entwicklungsteam sehr wichtig. Anhand der festgelegten Zeit pro User Story kann der Product Owner eine Release-Planung erstellen. Weil er genau weiß, welche User Stories im nächsten Release verarbeitet werden, kann er einschätzen, wann ein (Teil-) Produkt geliefert werden kann. Für das Entwicklungsteam sind die Einschätzungen der User Stories ebenfalls wichtig: So können die Teammitglieder gemeinsam entscheiden, wie viele Aufgaben sie beim nächsten Sprint übernehmen werden.
Vorbereitung des Treffens
Damit das Product Backlog Refinement erfolgreich verläuft, ist eine gute Vorbereitung unerlässlich. Zunächst muss der Product Owner festlegen, welche User Stories im Einzelnen ausgearbeitet werden sollen. Man sollte nicht zu weit im Voraus verschiedene User Stories ausarbeiten, weil man nicht wissen kann, ob diese User Stories in den nächsten Sprints behandelt werden. Es ist nämlich so, dass nur die User Stories mit der höchsten Priorität bearbeitet werden. Denken Sie daran: Die Arbeit mit Scrum erfordert ein hohes Maß an Flexibilität. Arbeiten Sie daher nur jene User Stories aus, die für die nächsten zwei oder drei Sprints eingeplant sind.
Anschließend ist es die Aufgabe des Product Owners, dafür zu sorgen, dass die User Stories gut formuliert werden, damit alle Mitglieder des Scrum-Teams diese auf Anhieb verstehen. Außerdem muss das Entwicklungsteam genau wissen, welche Anforderungen die Aufgabe erfüllen muss. Aus diesem Grund müssen für jede User Story vorab genügend Zulassungskriterien festgelegt werden.
Alle Informationen zum Product Backlog? Schauen Sie sich unser Animationsvideo an.
Das Product Backlog Refinement-Meeting
So wie bei allen anderen Treffen innerhalb des Scrum-Frameworks gibt es auch für das Product Backlog Refinement-Meeting eine Zeitvorgabe. Aus dem Scrum Guide geht hervor, dass hierfür höchstens 10 % der Gesamtzeit eines Sprints veranschlagt werden dürfen. Wenn ein Scrum-Team allerdings Vollzeit mit einem Sprint beschäftigt ist, darf das Product Backlog Refinement höchstens vier Stunden pro Woche in Anspruch nehmen.
Zudem müssen alle Mitglieder des Scrum-Teams am Meeting teilnehmen. Dies ist wichtig, weil der Product Owner alle User Stories erläutert. So kann sich das gesamte Entwicklungsteam über die geplanten Aufgaben informieren und ein Feedback zu den User Stories geben. Gegebenenfalls kann eine undeutlich formulierte User Story berichtigt werden. Abschließend ist das Entwicklungsteam für die Einschätzung der benötigten Zeit pro User Story verantwortlich. Dies wird mit dem Planning Poker realisiert.
Das Product Backlog Refinement kann vom Entwicklungsteam auch für die Aufgabenverteilung genutzt werden, wobei die User Stories in kleinere Arbeitsschritte unterteilt werden. So leistet das Team die Vorbereitungen für die Sprint Planning, wodurch dieses Treffen reibungsloser verlaufen wird.
Das Product Backlog Refinement-Meeting hat also viele Vorteile. So werden Erwartungen an das Projekt bereits in einem frühen Stadium sichtbar, User Stories in Teilaufgaben unterteilt und Unklarheiten beseitigt, damit sich das Entwicklungsteam auf den nächsten Sprint konzentrieren kann.
