Backlog Refinement kann auch als Backlogpflege bezeichnet werden und ist kein „echter“ Bestandteil von Scrum, sondern ein „Best Practice“, das sich über die Jahre etabliert hat. Das Meeting kann formell, oder auch informell stattfinden. Wie sich das Team dabei organisiert ist jedem Team selbst freigestellt. Die wesentlichen Punkte des Backog Refinement werden hier im folgenden zusammengestellt.
Zielsetzung
Das Backlog Refinement findet im Rahmen eines Workshops statt und hat ein gut gepflegtes Product Backlog zum Ziel. Die Anforderungen, User Stories oder Product Backlog Items werden im Backlog Refinement so präzisiert, dass sie in der nächsten Sprint Planungssitzung leicht eingeplant werden können. Dies bedeutet, dass die User Stories relevant sind und zu einem zu ihrer Priorität passenden Grad präzisiert und geschätzt sind.
Teilnehmer
Der Product Owner, Scurm Master und das Team treffen sich regelmäßig zum Backlog Refinement. Hierbei hat der Product Owner eine möglichst führende Rolle, da es in seinem eigenen Interesse liegt, die PBIs (Product Backlock Items) möglichst gut im Backlog zu pflegen. Er bringt daher vor allem die neuen oder veränderten PBIs in einer priorisierten Reihenfolge in das Meeting ein.
Ablauf
Vorbereitung erfolgt durch den Product Owner. Das Meeting kann zu Projektstart etwas länger dauern (bis zu 8h), aber im weiteren Projektverlauf, wenn man eingespielt ist und die meisten PBIs bereits besprochen hat kann es auch binnen 1-2 Stunden durchgeführt werden.
- Neue PBIs sind formuliert
- PBIs sind priorisiert
- Akzeptanzkriterien/-tests sind formuliert
- Bestands-PBIs sind ggf. auf Grund neuer Informationen aktualisiert
Ablauf des Refinement:
- Neue PBIs werden durch den Product Owner vorgestellt und das Team stellt Fragen bis es die Anforderungen verstanden hat und keine Fragen mehr offen bleiben (Definition of Ready).
- Notfalls werden PBIs geschärft, in kleinere Teile heruntergebrochen und konkretisiert
- die Priorisierung der bestehenden PBIs wird in Anbetracht der neu aufgenommenen Anforderungen neu bewertet
- Überflüssige PBIs werden entfernt
- Noch nicht geschätzte PBIs werden mit einer Schätzung versehen
- Bestehende Schätzungen werden in Anbetracht eventueller, neuer Informationen nochmals überprüft und notfalls korrigiert
Best Practices beim Backlog Refinement
- Es ist sinnvoll genügend PBIs vordefiniert zu haben, damit zwei weitere Sprints geplant werden könnten. Dies gibt zum einen den Ausblick auf zukünftige Aufgaben und zum anderen Planungssicherheit. Im Notfall können auch weitere PBIs z.B. in den laufenden Sprint aufgenommen werden, sofern alle anderen PBIs final bearbeitet wurden und noch Kapazitäten im Team frei sind, die einen Abschluss der PBIs im laufenden Sprint garantieren.
- Der Product Owner sollte die neuen PBIs gut verstehen und in einer gut bemessenen Größe bereitstellen (max. 3-4 Tage Bearbeitungszeit – in der Regel ca. 8 Storypoints). Vordefinierte Akzeptanzkriterien/Akzeptanztests sind hier sehr hilfreich und notwendig. Das PBI sollte so vorbereitet sein, dass theoretisch sofort mit der Implementierung begonnen werden kann.
- Die Integration aller Beteiligten sorgt für interdisziplinäre, aus verschiedenen Gesichtspunkten „durchdachte“ Lösungen.
- Ein fester Termin vereinfacht die Organisation und stellt sicher, dass das Meeting nicht vergessen wird.
- Das Backlog Refinement/Grooming klingt zunächst nach einem zusätzlichen Termin und damit nach zusätzlicher Belastung für das Team. Durch die gute Vorbereitung des Backlogs kann jedoch viel Zeit bei der Sprintplanungssitzung und bei der Besprechung von Anforderungen gespart werden.
- Es ist hilfreich, wenn zum einen der Product Owner bereits z.B. 24 Stunden vor dem Refinement Meeting mit der Erstellung/Anpassung der PBIs fertig ist und zum anderen das Team die PBIs bereits gelesen hat, um keine unnötige Zeit zu verlieren und vorbereitet in das Meeting zu gehen.
Tipp: Der Product Owner stellt am Ende des Meetings folgende zwei Fragen an das Team:
- Von allen PBI’s, die wir heute besprochen haben, bei welchem würdet ihr euch bei der Umsetzung am unwohlsten fühlen?
- Und bei welchem fühlt ihr euch nicht in der Lage eine vernünftige Schätzung abzugeben?
- Die PBIs, die bei diesen Fragen als Antwort genannt werden sollten zur Reduktion der Risiken genauer betrachtet und ggf. weiter durch den Product Owner bearbeitet werden.
- PBI’s mit hohen Risiken oder Unbekannten, seien es technische oder fachliche, sollten bis zum nächsten Refinement oder der Sprint Planungssitzung entweder vom Team oder Product Owner weiter bearbeitet werden.
Typische Fehler beim Backlog Refinement
- Das Backlog Refinement wird zu Beginn oder am Ende des Sprints durchgeführt. Zum Start eines Sprints liegen dem Team viele Aufgaben vor. Darum sollte man dem Team ein wenig Zeit geben die Arbeit aufzunehmen, wohingegen das Ende eines Sprint häufig arbeitsintensiv ist, um das Sprintziel zu erreichen und noch anstehende Arbeiten abzuschließen. Eine gute Zeit, um das Refinement Meeting durchzuführen ist daher kurz nach der hälfte des Sprints.
- Product Backlog Items sind nicht ausreichend präzisiert und es sind noch Punkte zur Klärung offen. Zeit, die das Team mit unklaren Anforderungen verbringt ist verloren, da es versucht Anforderungen zu „erraten“, die dann dennoch mit dem Kunden im Nachgang geklärt werden müssen. Dies ist verlorene Zeit, die sich das Team sparen kann. Gut vorbereitete PBIs sind daher pflicht.
- Schätzungen im Refinement sind nicht als final anzusehen. Solange eine Anforderung nicht ins Sprint Backlog übernommen wurde kann eine neue Idee zur Umsetzung die geschätzten Aufwendungen wieder verändern.
- Gleiches gilt für die Priorisierung von Anforderungen. Agile Entwicklung ermöglicht das flexible Einbringen von Änderungen – so auch an dieser Stelle.
