Gibt es so etwas wie ein Product Backlog Refinement Meeting?


Björn Schuster, Senior Consultant

Oft wenn ich Blogs zum Thema Scrum lese stolpere ich über die Aussage, dass das Product Backlog Refinement ein Meeting ist. Ich stolpere über diese Aussage, weil Product Backlog Refinement kontinuierlich erfolgen sollte und nicht nur zu einem festgelegten Zeitpunkt. Was sagen verschiedene Quellen zum Thema Product Backlog Refinement?

Scrum Guide

Im Scrum Guide wird das Meeting oder Event «Refinement» explizit nicht erwähnt. Der Scrum Guide kennt kein Ereignis, das sich Refinement nennt. Refinement wird beim Thema «Produkt Backlog» erwähnt. Der Scrum Guide beschreibt, was Refinement ist: der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden.

IREB RE@Agile

Der IREB RE@Agile Primer Lehrplan hält sich etwas vage in der Aussage, dass es die Aufgabe des Product Owners ist für «ready» Backlog Items zu sorgen, die im nächsten Planning Meeting eingeplant werden können.

Ansonsten hält sich der IREB RE@Agile Lehrplan seit 09/2020 recht stark an den Scrum Guide 2016. Die Ausnahme ist jedoch, dass der Product Owner oder der Requirements Engineer mit dem Development Team die Backlog Elemente verfeinern, bis die Definition of Ready erreicht wurde. Das Entwicklungsteam wird hier teilweise auch als Stakeholder bezeichnet.

Scaled Agile Framework (SAFe)

Programm Sicht

Refinement beinhaltet die Zusammenarbeit um die Beschreibung, Business Benefit Hypothese, Akzeptanzkriterien und Grösse in normalisierten Story points von Features zu definieren. Das Feature benötigt möglicherweise Prototypen oder eine andere Form der Erforschung durch ein Agile Team.

Team Sicht

Der Team Backlog muss immer ein paar Stories enthalten die ohne signifikante Risiken oder Überraschungen bereit für die Umsetzung sind. Agile Teams verwenden einen flussbasierten Ansatz um die Readiness des Backlogs sicherzustellen. Dies typischerweise durch das durchführen mindestens eines Backlog Refinement Workshops pro Iteration (oder sogar einen pro Woche). Der einzige Fokus des Backlog Refinement ist, die nächsten Stories (und Features, soweit geeignet) anzuschauen, zu diskutieren und ein erstes initiales Verständnis der Akzeptanzkriterien zu ermitteln. Der Backlog Refinement Prozess ist kontinuierlich und sollte nicht auf eine Timebox eines einzigen Meetings beschränkt sein. Teams die Behaviour-Driven-Development verwenden werden mehr Zeit vorab aufwenden um Akzeptanztests erstellen zu können. 

Large Scaled Scrum (LeSS)

Kontinuierliches Product Backlog Refinement (PBR) ist in jedem Sprint erforderlich, um Elemente im Backlog zu verfeinern, damit sie für zukünftige Sprints bereit sind für die Umsetzung. Schlüsselaktivitäten der PBR sind (1) das Aufteilen großer Elemente, (2) das Detaillieren von Elementen, bis sie bereit sind, und (3) das Schätzen. Im Sinne der empirischen Prozesskontrolle sagt Scrum nicht, wie man PBR durchführt, schlägt aber vor, dass das Team nicht mehr als 10% seiner Sprint-Kapazität dafür aufwendet. Es geschieht normalerweise „in der Mitte des Sprints“.

Hinweis! Die Verfeinerung von Elementen wird nicht separat vom Product Owner oder einer Business-Analyse-Gruppe durchgeführt – das würde den Lean-Waste durch Übergabe und Informationsstreuung erhöhen. Vielmehr macht das Team diese Arbeit – und nicht eine Teilmenge des Teams, sondern das ganze Team, da die Scrum-Regeln Untergruppen verbieten, die sich bestimmten Bereichen wie Analyse oder Testen widmen. (Übersetzt aus dem englischen Original)

Kanban

Kanban (für Softwareentwicklung, respektive Produktentwicklung) schweigt sich hierzu aus. Es gibt jedoch als Best Practice das sogenannte Replenishment Meeting, bei dem das Team zusammen entscheiden, welche möglichen Optionen als nächstes dran kommen. Ab diesem Moment wird die Lead-Time getracked. Somit muss zu diesem Zeitpunkt spätestens genügend über die zu erledigende Arbeit bekannt sein.

Refinement Meeting: ja oder nein?

Es gilt also festzuhalten, dass die Instanz für Scrum – der Scrum Guide –  das Refinement Meeting nicht kennt. Der Scrum Guide spricht von einer fortwährenden (ongoing) Tätigkeit.

Dies ist bei agilen Frameworks die Vorgehensweise: es liegt kein Mehrwert darin vorzugeben, wie das Refinement in einem spezifischen Kontext idealerweise erfolgen sollte, weil dies eben abhängig vom Kontext ist. Somit liegt es also am Team für sich herauszufinden, was aktuell die beste Herangehensweise ist.

Refinement Meeting als Blocker für das Scrum Team

Ich persönlich schliesse mich in diesem Punkt dem Vorschlag aus dem IREB RE@Agile Primer an. Ich setze meist ein Meeting für das ganze Scrum Team auf, damit die Zeit im Kalender entsprechend geblockt ist und es jedem Teammitglied klar ist, dass dies auch Teil der Aufgaben des Entwicklungsteams ist. Wenn das Entwicklungsteam als Ganzes am Refinement teilnimmt können auch verschiedenste Sichten in das Verfeinern der Backlog Elemente eingebracht werden (Front-End, Back-End, Testing, UX, …). Auch können die Backlog Elemente bereits geschätzt werden, was wieder einen wichtigen Hinweis zur Grösse der Backlog Elemente liefert (ob beispielsweise eine weitere Zerlegung erforderlich ist, wieviele Elemente vorbereitet werden sollten oder ob der Aufwand den erwarteten Ertrag rechtfertigt).

Es gilt jedoch zu betonen, dass das nicht die einzige Zeit ist, die das Entwicklungsteam oder einzelne Mitglieder des Entwicklungsteams mit dem Refinement verbringen werden. Neue Product Backlog Elemente, oder sogar bereits bekannte, werden in guten Teams regelmässig von Entwicklungsteammitgliedern weiter verfeinert. Dass der Product Owner dies auch mehr als nur in einem Meeting macht, versteht sich für mich von selbst.

0 thoughts on “Gibt es so etwas wie ein Product Backlog Refinement Meeting?”


Schreibe einen Kommentar