In Scrum wird “Product Backlog Refinement” auch als “Product Backlog Grooming” , “Backlog Estimation” (Schätzung) oder als “Story Time” bezeichnet. Ken Schwaber und Jeff Sutherland haben “Product Refinement” im Scrum Guide nicht direkt erwähnt (ab dem Scrum Guide 2013 ist es enthalten), es wird aber beschrieben, dass das Development Team ein wenig Zeit in jeden einzelnen Sprint für diese Tätigkeit reservieren sollte. Zum Beispiel, wenn ein Team zweiwöchige Sprints durchführt, sollte das Team sich ca. 10-15% der Scrum-Team Kapazität eines Sprints für das Product Backlog Refinement pro Sprint reservieren.
Der Zweck des Backlog Refinement ist es, die Product Backlog Items im Product Backlog so vorzubereiten, dass die Product Backlog Items die im Backlog “oben” stehen, möglichst gut für einen der nächsten Sprints vorbereitet sind. Sprich die Spitze des Product Backlogs wird verfeinert.
Verfeinerung des Backlogs bedeutet, dass über diese Product Backlog Items höchst mögliche Klarheit herrscht und diese somit auch “Akzeptanz Kriterien” enthalten sowie möglichst genau vom Development Team geschätzt wurden.
Eine weitere Tätigkeit der Verfeinerung des Product Backlogs ist das „Herunterbrechen“ von großen Product Backlog Items (oft als “Epics” bezeichnet) in die kleinere (wie z.B. “User Stories “). Idealer Weise sind diese Backlog Items von möglichst gleicher Größe, tendenziell lieber klein als groß. Eine „Best Practice“ sagt auf jeden Fall nicht größer als ein Fünftel des Sprints.
Ein großer Vorteil des Backlog Revinements ist, dass sich der Aufwand in den Scrum Planning Meetings für die oben beschriebenen Tätigkeiten deutlich reduziert. Es wird Riskio minimiert, da nicht erst im Planning Meeting Dinge wie Abhängigkeiten erkannt werden sondern eben frühzeitig etc.
Das kontinuierliche Arbeiten am Backlog mit Backlog Refinement kann man sich vorstellen wie das Abzahlen eines Hypothekendarlens in kleinen Schritten anstatt einen „großen Batzen“ auf einmal zu berappen.
Ein weiterer wichtiger Grund für das Backlog Refinement ist, dass der Scrum Product Owner mit Hilfe des Development Teams einen immer möglichst gut gepflegten und sauber geschätzten Product Backlog erhält. Dies erleichtert ihm ungemein bei Arbeiten wie Release Planungen und Abschätzungen zur (Teil)Produktfertigstellungen.
Erstveröffentlichung im Scrum-Trainings Blog
agilisten 