

Erfahren Sie, wie Sie Ihre Projektplanung effizient gestalten können. Nutzen Sie unsere Tipps und Tools, um Zeit und Ressourcen zu sparen. Appvizer bietet Ihnen alles, was Sie für eine erfolgreiche Projektplanung benötigen.
Das Medium für diejenigen, die das Unternehmen neu erfinden
Nein, das Product Backlog Refinement ist kein weiteres neues, wenig hilfreiches Meeting, das vom Scrum-Framework eingeführt wurde, ganz im Gegenteil.
Es ist seit 2013 im Scrum Guide aufgeführt, und wird in agilen Teams immer wichtiger, um die Planung des kommenden Sprints in Ruhe anzugehen.
Was ist das Backlog Refinement, und wie funktioniert es? Wir geben Ihnen auch einige Tipps, wie Sie Ihr Backlog effektiv aufbereiten können.
Um das Backlog Refinement vollständig zu verstehen, bedarf es zunächst eine Erklärung des Konzepts des Product Backlogs.
Das (Product) Backlog ist eine Liste von Anforderungen für ein Produkt oder ein Projekt, die in Form von User Storys (US) übersetzt werden, um die Bedürfnisse der Benutzer genau zu beschreiben. Das Backlog wird vom Product Owner erstellt und verwaltet und vom gesamten Team während des Sprint-Planungsprozesses konsultiert, um die Storys und Funktionalitäten auszuwählen, die während des Sprints entwickelt werden.
Das Backlog Refinement, auch Backlog Grooming genannt (auf deutsch “grooming”: pflegen), ist die Verfeinerung und Pflege des Backlogs in einem speziellen Scrum-Meeting während des Sprints.
Konkret dient das Backlog Refinement dazu:
Was ist der Unterschied zwischen dem Backlog Refinement und dem Sprint Planning?
Das Sprint Planning findet am ersten Tag des Sprints statt und zielt darauf ab, den Zweck des Sprints zu definieren und die User Storys auszuwählen, die das Team am Ende liefern möchte. Sie kann etwa 2 Stunden pro Woche dauern.
Das Backlog Refinement ist eine Zwischenbesprechung und ergänzt das Sprint Planning. Während des Sprints kann es mehrere geben und sie dient dazu, die Basis für das Sprint Planning vorzubereiten, das dann effizienter sein sollte.
Wer sollte an diesem Meeting teilnehmen? Alle Mitglieder des Scrum-Teams sollten daran teilnehmen:
👉 Der Product Owner ist für die Vorbereitung, Organisation und Leitung des Backlog Refinement Meetings verantwortlich.
Die regelmäßige Verwendung des Backlog Refinements hat viele Vorteile:
Laut Scrum Guide sollte maximal 10 % der Gesamtzeit eines Sprints für das Backlog Refinement aufgewendet werden.
In einem System ständiger Agilität ist es jedoch ratsam, mehrere Veranstaltungen zu halten, auch wenn dies eine Verkürzung der Dauer voraussetzt. Auf diese Weise kann der Product Owner die Entwicklung antizipieren und hat Zeit, seine User Story vor Ende des Sprints zu überarbeiten.
Zur Erinnerung: Der Product Owner ist dafür verantwortlich, eine Benutzeranfrage oder einen Bedarf so detailliert und klar wie möglich in eine User Story zu übersetzen.
Er*sie wird daher dem Rest des Teams die User Stories präsentieren, die er*sie fertiggestellt hat.
Damit soll sichergestellt werden, dass die Mitglieder des Entwicklungsteams die Anforderungen genau verstehen und dass sie Fragen stellen und diese diskutieren können. Der Product Owner kann sie dann anhand der Diskussionen ändern oder ergänzen.
Das Team kann dann die User Story validieren und mit ihrer Schätzung fortfahren.
👉 Falls das Entwicklungsteam den Bedarf nicht versteht, muss sich der Product Owner die Zeit nehmen, seine US zu überarbeiten und zu klären, um sie in der nächsten Sitzung erneut zu präsentieren.
Der nächste logische Schritt nach der Validierung der US ist ihre Schätzung durch die Entwickler.
Jedes Team hat seine eigenen Methoden und Werkzeuge, um sie zu schätzen. In der Praxis tendieren wir dazu, ein US in Aufwandspunkten (Story Points) und nicht in Zeiteinheiten zu schätzen.
Zu den gängigsten Aufwandschätzungsmethoden zählen:
Sie müssen selbst entscheiden, welche Methode am besten zu Ihrem Team und Ihren Projekten passt. Wenn es sich herausstellt, dass die Einschätzung einer User Story kompliziert wird, ist es besser sie in verschiedene kleinere US zu unterteilen, um klarer zu sehen.
💡 Gut zu wissen: Man schätzt (oder aktualisiert) die User Storys für den kommenden Sprint oder möglicherweise den darauffolgenden, aber man vermeidet weitere Schätzungen.
Wenn das Team die Schätzung einer User Story kennt, kann es damit beginnen, Prioritäten zu setzen.
Es können jedoch auch andere Prioritätskriterien ins Spiel kommen, insbesondere der funktionale Wert, der von wesentlicher Bedeutung ist. Deshalb ist es sinnvoll, die Prioritätsstufen nach dem Verhältnis von Wert und Aufwand zu bestimmen:
💡 Gut zu wissen: Eine Priorisierung kann für den gesamten Backlog vorgenommen werden, auch wenn die US nicht vollständig sind, da wir eine eher makroökonomische Sichtweise in diesem Schritt haben.
Und Sie? Haben Sie Ratschläge für einen Product Owner, der sich auf den Weg des Refinements begibt?