Wozu braucht man Backlog Refinement?

In Scrum wurde „Product Backlog Refinement“ früher gerne auch als „Product Backlog Grooming“ , „Backlog Estimation Meeting“ (Schätzung) oder als „Story Time“ bezeichnet. Ken Schwaber und Jeff Sutherland haben „Product Backlog Refinement“ 2013 in den Scrum-Guide aufgenommen. Dort wird beschrieben, dass sich das Development Team und der Product Owner ein wenig Zeit in jeden einzelnen Sprint für diese Tätigkeit reservieren sollte (bis zu 10% der Development Team Kapazität). Sprich, wenn ein Scrum-Team zweiwöchige Sprints durchführt, sollte das Team sich zwischen 4 – 10 Stunden 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 z.B. auch „Akzeptanz Kriterien“ enthalten sowie möglichst gut 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 kleinere Einheiten (wie z.B. „User Stories „). Idealer Weise sind diese Backlog Items von ungefähr gleicher Größe, tendenziell lieber klein als groß. Eine „Good Practice“ sagt: „das größte Item sollte nicht größer als ein Fünftel der Sprint Kapazität des Teams einnehmen“.

Ein großer Vorteil des Backlog Refinements ist, dass sich der Aufwand im Sprint Planning für die oben beschriebenen Tätigkeiten deutlich reduziert. Es wird Riskio minimiert, da nicht erst im Sprint-Planning Dinge wie Abhängigkeiten erkannt werden, sondern eben deutlich früher (in vorhergehenden Sprints).

Das kontinuierliche Arbeiten am Backlog in Form des Backlog Refinements kann man sich vorstellen wie das Abzahlen eines Hypothekendarlehns 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 beibehält. Dies erleichtert ihm ungemein bei Arbeiten wie Release Planungen und Abschätzungen zur (Teil)Produktfertigstellungen.