Wozu Backlog Refinement?

Product Backlog Refinement, früher auch bekannt als „Product Backlog Grooming“ , „Backlog Estimation Meeting“ (Schätzung) oder als „Story Time“.

Ken Schwaber und Jeff Sutherland haben „Product Backlog Refinement“ 2013 in den Scrum-Guide aufgenommen. Dort wird beschrieben, dass sich das Scrum Team ein wenig Zeit in jeden einzelnen Sprint für diese Tätigkeit reservieren sollte. Praktikabel ist z.B. bis zu 10% der Scrum 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.

Während des Product Backlog Refinement überprüfen die Developer, der Product Owner und ggf. weitere Beteiligte die Elemente im Backlog und klären ihre Anforderungen, Abhängigkeiten und Abnahmekriterien. Sie können auch die Schätzungen für den Aufwand, der für die Fertigstellung der Arbeit erforderlich ist, überarbeiten und die Elemente auf der Grundlage ihres Wertes für das Unternehmen und ihrer Entwicklungsreife priorisieren.

Der Zweck des Backlog Refinement ist es, dass die Elemente im Backlog klar verstanden, gut definiert und priorisiert sind. So dass die Product Backlog Items im Backlog gut vorbereitet für die Abarbeitung sind. Sprich, Product Backlog Items die im Backlog „oben“ stehen, möglichst gut für einen der nächsten Sprints vorbereitet sind und abgearbeitet werden können. D.h. die Spitze des Product Backlogs wird ständig verfeinert.

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 kleiner 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 Product 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 der Developer einen immer gut gepflegten und sauber geschätzten Product Backlog beibehält. Dies erleichtert dem Product Owner Arbeiten wie Release Planungen und Abschätzungen zur (Teil)Produktfertigstellungen.