<< Zurück zur Übersicht

Wie gehe ich das Product Backlog Refinement an?

Das Product Backlog Refinement ist nicht als separates Event innerhalb des Scrum Frameworks definiert. Ein gutes Product Backlog Refinement verringert jedoch das Risiko, dass die Arbeit während eines Sprints nicht geliefert wird. Aus dem Scrum Guide lässt sich folgende Definition für die das Product Backlog Refinement ableiten:

„Die Ausarbeitung des Product Backlogs („Refinement“) ist die Reduzierung und weitere Definition von Product Backlog Items in kleinere, präzisere Items. Dies ist eine laufende Aktivität, um Details wie Beschreibung, Bestellung und Größe hinzuzufügen.“

Aktivitäten während des Product Backlog Refinement

Nach Simon Flossmann (Professioneller Scrum Master via Scrum.org) kann das Product Backlog Refinement in die folgenden Schritte unterteilt werden:

  • Zunehmende Einsicht in die zu leistende Arbeit;
  • Setzen Sie Prioritäten für die Items im Product Backlog;
  • Schätzung des Umfangs der Items im Product Backlog;
  • Reduzieren Sie die Größe der Product Backlog Items.
1. Verbesserung des Verständnisses für die zu leistende Arbeit

Erfolgreiche Scrum Teams beginnen nicht mit einer einfachen Implementierung von Funktionen. Sie beginnen damit, die Probleme des Kunden zu verstehen und untersuchen mögliche Lösungen.

Eine Möglichkeit, Einblicke in die Bedürfnisse der Kunden zu gewinnen, ist die Arbeitsweise von Liberating Structure, die „User Experience Fishbowl„. In dieser Form haben Sie zwei Gruppen: die Stakeholder und das Scrum Team. Dann wird das folgende Arbeitsformat verwendet:

  • Die Stakeholder erörtern ihre Bedürfnisse in Bezug auf die User Stories im Product Backlog anhand der folgenden Fragen: „Stellen Sie sich vor, dieses Feature/diese Funktionalität wäre bereits Teil des Produkts; wie, wann und warum würden Sie es/sie verwenden. Welche Schritte gehen Sie bei der Nutzung durch? Warum ist sie nützlich? Was würde sie weniger nützlich machen?“
  • Das Scrum Team verfolgt das Gespräch; anschließend diskutiert das Scrum Team das Gehörte und formuliert neue Fragen, die den Stakeholdern in einer neuen Runde vorgelegt werden.

Diese Arbeitsmethode gibt Aufschluss über den Wert, den ein Feature/eine Funktion für die Stakeholder hat, und hilft so, große Teile des Product Backlogs in kleinere Teile zu unterteilen, die für die Stakeholder noch wertvoll sind.

2. Priorisierung der Items im Product Backlog

Die Priorisierung der Items im Product Backlog ist in erster Linie eine Tätigkeit des Product Owners. Allerdings braucht er die Hilfe der Stakeholder und des Scrum Teams. Dies unterstützt nicht nur die Priorisierung, sondern gibt auch Aufschluss über die Funktionen, die für die Stakeholder wirklich von Nutzen sind.

Bei der folgenden Methode werden die Stakeholder so weit wie möglich in die Bestimmung der Priorität der Items des Product Backlogs einbezogen.

  • Jedes Item des Product Backlogs wird auf einer separaten Karte vermerkt;
  • Die Karten werden gemischt und als Stapel umgedreht auf den Tisch gelegt;
  • Die oben liegende Karte wird umgedreht und als Referenzkarte neben den Kartenstapel gelegt;
  • Die nächste Karte wird vom Stapel genommen und die Stakeholder geben an, ob sie mehr oder weniger wichtig ist als die Referenzkarte auf dem Tisch. Je nach Ergebnis wird die Karte unter oder über die Referenzkarte gelegt;
  • Alle Karten im Deck durchlaufen diesen Prozess.

Anschließend erhält man einen klaren Überblick über die Priorität, die die Stakeholder den verschiedenen Items beimessen.

3. Schätzung der Größe der Items im Product Backlog

Der Zweck der Schätzung des Umfangs der Items im Product Backlog besteht darin, eine klare Schätzung des Gesamtarbeitsumfangs zu erhalten. Der Umfang wird im Verhältnis zu anderen Items im Product Backlog oder Items, die in der Vergangenheit realisiert wurden, geschätzt.

In vielen Fällen wird das „Planning Poker“ als Arbeitsmethode verwendet, um die Größe der Product Backlog Items zu schätzen. Die Methode der „magischen Schätzung“ ist eine alternative Methode.

  • Zur Angabe der Größe eines Items verwenden wir die Fibonacci-Folge 1,2,3,5,8,13,21, ergänzt durch ein Fragezeichen (?);
  • Ein zufälliges Item des Product Backlogs wird von allen Entwicklern gemeinsam mit einer Schätzung (Zahl aus der Fibonacci-Folge) versehen. Die Schätzung dieses Items dient als Referenz für die Fortführung;
  • Die restlichen Items werden unter den Entwicklern verteilt;
  • Die Entwickler geben dem ihnen zugewiesenen Item eine Nummer aus der Fibonacci-Folge, die die Größe im Verhältnis zum Referenzitem darstellt. Wenn jemand die Aufgabe nicht versteht, wird ein Fragezeichen gesetzt;
  • Wenn für alle Items ein Kostenvoranschlag vorliegt, überprüfen alle Entwickler die Kostenvoranschläge für alle Items. Wenn sie mit der/den Schätzung(en) auf einer Karte nicht einverstanden sind, fügen sie ihre eigene Schätzung hinzu;
  • Falls zu einem Item kein Konsens erzielt werden kann, kann das Item vom Product Owner diskutiert und eventuell weiter erläutert werden. Wenn die Werte nahe beieinander liegen, kann man sich für den Wert zwischen den verschiedenen Schätzungen entscheiden. Wenn vor einem Diagramm ein Fragezeichen steht, wird der Product Owner zusätzliche Klarstellungen vornehmen.

Das Ergebnis ist eine Schätzung aller Items eines Product Backlogs im Verhältnis zu einem Referenzitem.

4. Verkleinerung der Product Backlog Items

Product Backlog Items werden verkleinert, um sicherzustellen, dass sie in einem Sprint geliefert werden können, aber auch um zu gewährleisten, dass die Items sofort nach der Lieferung einen Mehrwert bieten.

Sie können Items auf folgende Weise verkleinern:
  • Besteht ein Item aus aufeinanderfolgenden Schritten (einem Workflow), kann es nach den Schritten im Workflow unterteilt werden.
    – Ein Item, das beschreibt, dass ein Kunde die Artikel im elektronischen Warenkorb bezahlen kann, kann wie folgt unterteilt werden:
    *Als Kunde kann ich mich anmelden
    *Als Kunde kann ich meine Bestellung bezahlen
    *Als Kunde erhalte ich eine Bestätigung meiner Bestellung per Post

  • Die Funktionalität besteht oft aus Schritten, die in den meisten Fällen verwendet werden (der Happy Flow) und solchen, die in Ausnahmen verwendet werden (Unhappy Flow). Die Posten können entsprechend dem Happy- und Unhappy Flow verkleinert werden.
    – Das Item, das beschreibt, dass ein Kunde sich einloggen kann, kann wie folgt verkleinert werden:
    *Happy Flow: Als Kunde kann ich mich mit meinem Konto anmelden;
    *Unhappy Flow: Wenn es mir nicht gelingt, mich einzuloggen, kann ich mein Konto zurücksetzen.

Die Bedeutung des Product Backlog Refinement

Wie wir bereits erwähnt haben, ist das Product Backlog Refinement nicht als separates Ereignis innerhalb des Scrum Frameworks definiert. Sie findet im Rahmen des Sprint Planning statt, aber auch in speziell eingerichteten Workshops. Das Product Backlog Refinement gibt Aufschluss darüber, was geliefert werden soll und welchen Wert dies hat, wie groß der Arbeitsumfang ist und wie wichtig die einzelnen Items sind. Ein gutes Produkt Backlog Refinement ist eine Voraussetzung für die Durchführung erfolgreicher Sprints.

Quelle: Simon Flossmann

Autor

Mehr blogs

Gepostet in

Trainingsangebote

Klicken Sie auf das Bild, um alle unsere Agile- und Scrum-Kurse anzuzeigen.

Laden Sie unser Scrum Sprint Package kostenlos herunter und starten Sie noch heute.

Neue Fachartikel als Newsletter zugeschickt bekommen

Scrum Sprint Package Banner
Füllen Sie das Formular aus und Sie erhalten das Sprint Package per E-Mail.

Neugierig auf Scrum?

Fordern Sie unverbindlich und kostenlos das Whitepaper an!