Willkommen zum 7. Artikel der „Scrum im Selbststudium“-Artikelreihe. Solltest du den letzten Artikel verpasst haben, findest du ihn hier.
Wie sich das Produkt in der Zukunft möglicherweise entwickeln wird, spiegelt sich im Product Backlog wider.
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 nichtfunktionellen 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
Ein detaillierter Blick auf die Begriffe:
- 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:
- 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.
Wenn du Fragen hast, schreibe sie in die Kommentare. Wenn der Artikel für dich hilfreich war, dann gib ihm einen Daumen nach oben. Morgen geht es weiter mit Teil 8: Die Gegenwart: Das Sprint Backlog