Willkommen zum 7. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.

Im letzten Teil wurde deutlich, dass über die Artefakte Product Backlog, Sprint Backlog und Inkrement die notwendige Transparenz und ein einheitliches Produktverständnis geschaffen wird. Die drei Artefakte sind als Stationen einen Zeitachse zu verstehen: Vergangenheit, Gegenwart und Zukunft. In diesem Teil schauen wir auf das Product Backlog, das widerspiegelt, wie sich das Produkt in der Zukunft entwickeln wird.

Welche Richtung das Produkt einschlagen soll, wird im Produkt-Ziel festgehalten.

Das Produkt-Ziel hilft dabei, Fokus in der Arbeit im Product Backlog zu gewährleisten. Es erlaubt dem Scrum-Team, sich auf ein einziges langfristiges Ziel für das Produkt festzulegen.

„Das Produkt‐Ziel beschreibt also das langfristige Ziel für das Scrum Team. Das Produkt‐Ziel befindet sich im Product Backlog und kann dem Team als Planungsziel dienen. Der Rest des Product Backlogs entsteht, um zu definieren, ‚was‘ das Produkt‐Ziel erfüllt.“ – Scrum Guide, 2020

Das Scrum-Team verpflichtet sich dazu, nur ein Produkt-Ziel zu verfolgen.

„Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht.“ – Scrum Guide, 2020

Was alles erstellt werden kann, um ein Produkt-Ziel zu erreichen, ist im Product Backlog zu beschreiben. Jede Idee, Hypothese, Funktion, User Story, jeder Use Case, alle nicht-funktionellen Anforderungen, jeder Fehler oder jede Aufgabe, die das Scrum-Team derzeit als notwendig ansieht, um das Produkt-Ziel zu erreichen, werden im Product Backlog durch ein einzelnes Element dargestellt.

„Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.“ – Scrum Guide, 2020

Während das Scrum-Team auf das Produkt-Ziel hinarbeitet, ändert sich das Product Backlog kontinuierlich, um neue Erkenntnisse und Möglichkeiten widerzuspiegeln, die sich während dieser Arbeit ergeben. Es werden Einträge ergänzt, entfernt, geändert und umsortiert. Deshalb beschreibt der Scrum Guide das Product Backlog so:

„Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden.“ – Scrum Guide, 2020

Die Begriffe emergent und geordnet sind im Kontext des Product Backlogs folgendermaßen einzuordnen:

Emergent bedeutet, dass sich die Einträge in der Liste verändern, wenn das Scrum-Team neue Erkenntnisse über das Produkt, die Nutzer, die Kunden, den Markt oder die Technologie gewinnt.
Geordnet bedeutet, dass es eine eindeutige Reihenfolge bei den Einträgen im Produkt Backlog gibt. Jedes Mitglied des Scrum-Teams und jeder Stakeholder kann zu jedem Zeitpunkt erkennen, welcher Eintrag im Moment der Wichtigste ist und die Spitze der Liste bildet.

Erst das Refinement macht den Product Backlog wirklich transparent

Nicht alle Einträge im Product Backlog sind von Beginn an klein genug, damit das Scrum-Team sie innerhalb eines Sprints umsetzen kann. Und nicht alle Einträge sind gut genug verstanden, damit das Scrum-Team weiß, welches Problem gelöst werden soll.

Erst wenn die Einträge des Product Backlogs gut genug verstanden wurden und klein genug sind, sind sie wirklich transparent. Diesen Transparenzgrad erlangen die Teammitglieder in der Regel durch Refinement‐Aktivitäten.

„Product‐Backlog‐Einträge, die durch das Scrum-Team innerhalb eines Sprints abgeschlossen werden können (Done), gelten als bereit für die Auswahl in einem Sprint‐Planning‐Event.“ – Scrum Guide, 2020

Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dabei handelt es sich nicht um ein formales Event in Scrum, sondern das Refinement beschreibt eine fortlaufende Aktivität. Es kann deshalb während des Sprints, aber auch im Sprint Planning oder im Sprint Review passieren. Die Verfeinerung des Product Backlogs kann auf unterschiedliche Art und Weise stattfinden.

Der Scrum Guide hält fest, dass im Refinement Details wie Beschreibung, Reihenfolge und Größe ergänzt werden.

„Die Attribute variieren oft je nach Arbeitsumfeld.“ – Scrum Guide, 2020

Beispiele für Refinement-Aktivitäten sind:

Klärung von offenen Fragen bei Product-Backlog-Einträgen, die zu unklar sind, um mit der Arbeit daran zu beginnen. Dies sollte vorzugsweise direkt mit dem Stakeholder geschehen, für den dieser Eintrag ist.
Zerlegung der Einträge im Product Backlog, die zu umfangreich sind, um sie in einem einzigen Sprint abzuschließen.
Neuordnung der Product-Backlog-Einträge, damit die kommenden Sprints so reibungslos und wertvoll wie möglich sind.
Hinzufügen oder Entfernen von Einträgen aus dem Product Backlog, wenn sich neue Erkenntnisse ergeben.
Schätzung des Aufwands für die Umsetzung bestimmter Product-Backlog-Einträge.

Die Verfeinerung des Product Backlogs sollte also nicht als formalisiertes Meeting verstanden werden, das einmal während des Sprints stattfindet und an dem alle Teammitglieder teilnehmen, sondern als eine Reihe von fortlaufenden Aktivitäten zur Verfeinerung der Arbeit am Product Backlog für die kommenden Sprints. Barry Overeem, der Autor von „Die 8 Scrum-Master-Haltungen“, bezeichnet die Einträge im Product Backlog als Erinnerungen an Unterhaltungen, die das Scrum-Team mit seinen Stakeholdern führen sollte. Und die Verfeinerung ist ein fortlaufender Prozess, bei dem diese Gespräche geführt werden. Aus meiner Sicht ist diese Beschreibung sehr treffend, da sie die Idee von User Stories erweitert.

Ausblick: Im nächsten Teil schauen wir uns „die Gegenwart“ an: Das Sprint Backlog.

Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.