Product Backlog Refinement: das Scrum-Meeting für einen effizienteren Sprint

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:

• die Product Backlog Items neu zu ordnen,
• den erforderlichen Aufwand der User Storys abzuschätzen (oder neu zu schätzen),
• den funktionalen Wert jeder US zu bestimmen, um die Priorisierung zu erleichtern,
• US zu streichen (falls erforderlich),
• US hinzuzufügen (falls erforderlich).

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,
• der Scrum Master,
• das Entwicklungsteam,

👉 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:

• diese vorbereitende Arbeit bringt Klarheit in die Planung und Entwicklung des nächsten Sprints,
• sie verfeinert das Verständnis des Bedarfs,
• bereitet die Schätzung der User Storys vor,
• ermöglicht eine Zwischenbilanz,
• und kann die Dauer des Sprint Planning Meetings verkürzen.

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:

• Das Planning Poker,
• Das Bucket System,
• Die T-Shirt-Größen.

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:

• Priorität 1 (P1): hoher Geschäftswert und leicht zu entwickeln,
• Priorität 2 (P2): hoher Geschäftswert und schwer zu entwickeln
• Priorität 3 (P3): geringer Geschäftswert und leicht zu entwickeln,
• Priorität 4 (P4): geringer Geschäftswert und schwer zu entwickeln.

💡 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.

• Tipp 1: Als Product Owner bereiten Sie die Präsentation der User Storys gründlich vor, indem Sie dem Team Ihre Überlegungen erläutern, was sie Ihrer Meinung nach beitragen können usw. Je enthusiastischer und klarer Sie sind, desto wahrscheinlicher ist es, dass das Team Ihre Produktvision akzeptiert und das US validiert.
  
  
• Tipp 2: Akzeptieren Sie Fragen, Kommentare und negatives Feedback. Sie werden darin bestimmt etwas Konstruktives finden, das Ihr Denken und damit auch Ihre User Story bereichern wird.
  
  
• Tipp 3: Warten Sie nicht bis Sie alle Ihre US-Aktivitäten abgeschlossen haben, um den Backlog Refinement abzuarbeiten. Die fertigen Storys sollten regelmäßig während schnellen Backlog Refinements präsentiert werden, um zu erkennen, ob sie noch bearbeitet werden müssen, da sonst der nächste Sprint gefährdet ist. Vermeiden Sie den Tunneleffekt!

Und Sie? Haben Sie Ratschläge für einen Product Owner, der sich auf den Weg des Refinements begibt?