Product Backlog Refinement
in Scrum
Was ist das Product Backlog Refinement?
Damit das Scrum Team ein gemeinsames Verständnis von der Ausrichtung des Produktes hat und sich diese im Product Backlog widerspiegelt, pflegen Entwickler und Product Owner das Product Backlog gemeinsam. Dieser kontinuierliche Prozess der Backlog-Pflege wird als Product Backlog Refinement bezeichnet. Dabei steht sowohl die Vorbereitung des nächsten Sprints wie gröbere perspektivische Themen im Fokus vom Refinement in Scrum.
Weitere Infos zum
Backlog Refinement
Product Ownership ist ein Teamsport
Der PO ist zwar in Scrum dafür zuständig, das Product Backlog zu pflegen und sicherzustellen, dass der kommende Sprint gut vorbereitet ist. Um diesem Anspruch gerecht zu werden, ist der PO auf den Input von den Entwicklern angewiesen.
Für folgende Dinge ist die Einbindung der Entwickler ins Product Backlog Refinement unerlässlich:
- Um sicherzustellen, dass Backlog-Items wirklich Ready sind und es keine bösen Überraschungen im Planning gibt.
- Um grobe Backlog-Items früh richtig einzuschätzen, um dann aufbauend auch proaktiv die Erwartungen der Stakeholder zu managen.
- Um große Backlog-Items sinnvoll zu splitten, um aus den ersten minimalen Versionen möglichst viel zu lernen.
- Um weitere Impulse für eine effektive Ausgestaltung des Produktes in Richtung des Sprint-Ziels zu bekommen.
- Um die Entwickler als Partner bei der Produktentwicklung auf Augenhöhe aufzubauen, die ihre Ergebnisse im Sprint Review einordnen können und die Ausgestaltung proaktiv mitgehalten können.
Ohne die Unterstützung kann der PO faktisch nicht seinem Job gerecht werden. Product Ownership ist ein Teamsport. Nur schlechte Scrum Teams lassen hier ihren PO im Stich und lassen ihn sich an der anspruchsvollen Aufgabe alleine aufzureiben.
Sprint-Vorbereitung braucht das Backlog Refinement
Um eine reibungslose Planung des nächsten Sprints zu organisieren, ist die Vorbereitung des nächsten Sprints ein zentraler Bestandteil des Backlog Refinements.
Um gut vorbereitet in den nächsten Sprint zu gehen, braucht das Scrum Team genügend Backlog-Items, die Ready sind und ein gutes Verständnis zum aktuellen Produktschwerpunkt, um sinnvoll ein Sprint-Ziel setzen zu können.
Dazu bereiten gute Scrum Teams 150-200 % vor von dem, was sie üblicherweise in einem Sprint schaffen. So kann man passende Items zu einem Sprint-Ziel bündeln oder Backlog-Items mit honen Synergien zueinander auswählen.
Für eine effektive Durchsprache der Backlog-Items greifen hier viele Scrum Teams auf agile Schätztechniken zurück. Dabei ist das fokussierte Gespräch, die eine Schätzung formiert, mindestens genauso wichtig wie die Schätzung selbst.
Falls Backlog-Items zu groß sind, um sie im Sprint zu schaffen, werden diese hier gesplittet.
Mit einer solchen Vorbereitung sollten im Sprint Planning nur noch einzelne neue Items durchgesprochen werden müssen und so immer auch an den wichtigsten Themen im nächsten Sprint gearbeitet werden.
Ein kontinuierlicher Prozess, nicht bloß ein Sprint Refinement
Viele Scrum Teams reduzieren das Product Backlog Refinement auf die Vorbereitung vom kommenden Sprint. Sie machen quasi aus dem Product Backlog Refinement ein Sprint Refinement.
Da wir als gutes Scrum Team aber auch in der Lage sein wollen, die Erwartungen der Stakeholder proaktiv zu managen und früh die richtigen Akzente in der Ausgestaltung des Produktes setzen wollen, reicht die bloße Durchsprache der nächsten Backlog-Items nicht aus.Deswegen definiert der Scrum Guide das Product Backlog Refinement als kontinuierlichen Prozess.
Gute Scrum Teams sprechen im Product Backlog Refinement auch neue große Backlog-Items durch und checken, ob die Ausrichtung zum Produktziel noch grundsätzlich passt.
Üblicherweise greifen hier gute Scrum Teams auf dieselben Schätz- und Splittingmethoden zurück wie bei den Items für den nächsten Sprint.
Hier schaffen sie aber den Rahmen früh fokussiert die richtigen Dinge anzusprechen und diese in die Produktausgestaltung einbeziehen zu lassen.
Dies ist gerade in klassischen Umfeldern notwendig, weil hier angrenzende Teams einen größeren Vorlauf für Zulieferungen brauchen und auch das Umfeld konkrete Abschätzungen für Budgets & Co erwarten.
Wann Backlog Refinement?
Scrum lasst als minimales Rahmenwerk auch hier bewusst offen, wie und wann wir die gemeinsame Pflege des Product Backlogs organisieren.
Gängige Variationen das Product Backlog Refinements zu organisieren:
- Jeden Freitag ganz unabhängig vom Sprint-Wechsel
- Immer mittwochs, wenn kein Sprint-Wechsel stattfindet
- Jeden Tag 15 Minuten nach dem Daily Scrum
Um den zeitlichen Umfang von dem Product Backlog Refinement möglichst klein zu halten, besprechen in manchen Umgebungen einzelne Entwickler die Backlog-Items mit dem Product Owner vor.
Product Backlog Refinement Teilnehmer
Für eine effektive Teamarbeit ist es aber essenziell, dass alle Entwickler ein Verständnis für die Themen im Backlog haben. Es reicht nicht nur aus, wenn jeder Entwickler seine Themen kennt. Deswegen ist das eigentliche Product Backlog Refinement üblicherweise mit allen Entwicklern.
Möchtest du Scrum für deine Zwecke effektiver nutzen?
Product Backlog Refinement Beispiele
Im Rahmen der #remotescrum-Initiative hatte Ralf Kruse einen Austausch zu Erfahrungen das Sprint Planning Remote durchzuführen organisiert.
Nachfolgend die Vorstellung der Praxisbeispiele aus dem Event:
