Theorie "Product Backlog"

Was ist der Product Backlog?¶

Zu Beginn des Projektes wird der Product Backlog erstellt. Der Product Backlog ist das erste Scrum Artefakt, welches wir Ihnen hier vorstellen.

Der Product Backlog ist die zentrale Sammelstelle für die Anforderungen an das Produkt aus Sicht des Kunden. Daher unterliegt es der Verantwortung des Product Owners.

Es enthält jedweden Eintrag, der zur Erarbeitung des Endproduktes notwendig ist. Diese Einträge werden auch als Product Backlog Items bezeichnet. Dazu gehören Merkmale, Funktionen, Anforderungen, aber auch Korrekturen, Darstellungen, oder auch Benutzeroberflächen (GUI - Graphical User Interfaces).

Der Product Backlog

• unterliegt der Verantwortung des Product Owners.
• enthält eine Liste der gewünschten Funktionalitäten.
• kann als wesentlichen Bestandteil User Stories enthalten.
• enthält Einträge, die nach Wichtigkeit (z. B. Geschäftswertbeitrag) priorisiert und abgeschätzt werden. Die obersten Einträge werden im kommenden Sprint bearbeitet.
• wird, wenn Anlass dazu besteht, nach Maßgabe des Product Owners während der Projektlaufzeit gepflegt und aktualisiert (refinement).
• unterliegt einer konstanten Veränderung und ist das Zentrum agiler Anpassung. Es sollte mindestens einmal vor jedem Sprint Planning Meeting aktualisiert werden.
• soll den DEEP-Kriterien (detailed appropriately, estimated, emergent, prioritised) genügen.

Priorisieren¶

Sobald der erste Pool von Anforderungen ermittelt wurde, werden die Einträge im Product Backlog im nächsten Schritt priorisiert, das heißt, nach ihrer Wichtigkeit geordnet. Einträge, die weiter oben im Product Backlog aufgelistet sind, sind klarer und detaillierter als weiter unten gelistete Einträge. Des Weiteren bietet es sich an, User Stories, welche leichter umsetzbar sind, weiter oben im Product Backlog einzuordnen. User Stories, deren Umsetzung aufwändiger ist, sind demnach weiter unten im Product Backlog zu finden.

Die obersten Einträge sind die PBIs, die der Product Owner zuerst umgesetzt haben möchte. Das Kriterium für die Priorisierung ist üblicherweise der Geschäftswertbeitrag, den die Umsetzung der jeweiligen User Story liefert. Aber auch andere Kriterien können eine Rolle spielen, wie etwa Entwicklungskosten, die Wertschätzung oder Risiken.

Als Entscheidungshilfe kann auch das Kano-Modell zu Rate gezogen werden.

Sollten während des Projektes neue Erkenntnisse gewonnen werden, sodass eine Repriorisierung nötig wird, kann diese jederzeit vom Product Owner gefordert werden. Somit wird die bisherige Priorisierung verändert.

Das Kano-Modell¶

Das Kano-Modell stellt graphisch den Zusammenhang zwischen der Kundenzufriedenheit und der realisierten Qualitätseigenschaft dar. Die Kundezufriedenheit bewegt sich zwischen „niedrig" und „hoch" und die Qualitätseigenschaften können auf eine Skala zwischen „nicht erfüllt" und „realisiert" dargestellt werden. Beim Kano-Modell gibt es drei zentrale Merkmale:

• Basismerkmale
  • sind selbstverständlich und werden vom Kunden vorausgesetzt.
  • stellen Kunden nicht zufriedener, wenn sie vorhanden sind.
  • stellen Kunden überproportional unzufrieden, wenn sie nicht vorhanden sind.
• Leistungsmerkmale
  • werden vom Kunden aktiv gefordert.
  • können z. B. durch Marktbeobachtungen herausgefunden werden.
  • stellen Kunden zufrieden, wenn sie vorhanden sind.
  • stellen Kunden unzufrieden, wenn sie nicht vorhanden sind.
• Begeisterungsmerkmale:
  • sind nicht selbstverständlich und Kunden fordern diese Merkmale nicht.
  • stellen Kunden nicht unzufriedener, wenn sie nicht vorhanden sind.
  • stellen Kunden überproportional zufrieden, wenn sie vorhanden sind.

Product Backlog Items¶

In jedem Sprint, d. h. in jedem Entwicklungszyklus, wird eine von den Developern festgelegte Anzahl der obersten Einträge aus dem Product Backlog in ein Increment umgesetzt. Damit dies möglich ist, müssen die Einträge oder User Stories im oberen Bereich vom Arbeitsaufwand her so gestaltet sein, dass ihre Umsetzung in den kurzen Sprintzyklen möglich ist.

Weiter unten im Product Backlog gibt es Einträge unterschiedlichster Größe: Weitere Tasks, User Stories, Epics und Themes. Epics sind sehr umfangreiche User Stories, die zum Zeitpunkt ihrer Bewertung als Epic noch zu groß für eine User Story sind. Themes sind unterschiedliche User Stories, die zu einem gemeinsamen Themenbereich zusammengefasst sind.

Sobald diese Einträge in den oberen Bereich des Product Backlog verschoben werden, müssen sie in feingranulare Einträge oder User Stories zerteilt werden, um ihre Umsetzbarkeit sicherzustellen.

Wenn ein Eintrag in die technische Umsetzung überführt wird, wird dieser aus dem Product Backlog entfernt und die weiter unten aufgeführten Einträge rutschen nach. Tasks, welche die "Definition of Ready" erfüllen und zum Sprint Goal passen, sind zur Verschiebung in den Sprint Backlog bereit. Der Product Backlog ändert sich dabei fortlaufend.

Sobald ein Eintrag aus dem Product Backlog der "Definition of Done" entspricht und vom Product Owner abgenommen wurde kann er als abgeschlossen betrachtet werden.

Commitment: Das Product Goal¶

Der Kompass der Entwicklung¶

Das Product Goal ist die Verpflichtung, das sogenannte Commitment des Scrum Teams zum Product Backlog und dient als Kompass für die Entwicklung des aktuellen Projektes. Es beschreibt, anders als (vormals) die Product Vision, ein konkretes Ziel, welches mit dem Scrum Projekt verfolgt und durch die Sprints erzeugt wird.

Bei der Erarbeitung des Product Goals sollten möglichst Kunden und Anwender miteinbezogen werden. Der Product Owner entwickelt für die Stakeholder des Projektes ein gemeinsames Verständnis der Zielvorstellung und legt die Rahmenbedingungen fest, die der Vermarktung des Produktes und dessen wirtschaftlichem Erfolg dienen.

Dabei geht es um folgende Fragen:

Backlog Refinement: Aktualisierung des Product Backlogs¶

Der Product Backlog sollte in regelmäßigen Abständen einer Bewertung und Überprüfung unterzogen werden. Diese Bewertung und Überprüfung erlaubt es die Einträge im Product Backlog durchzusehen und dahingehend zu überprüfen, ob sie noch aktuell sind und ob sie die Interessen des Kunden korrekt wiedergeben. Zur Aktualisierung des Product Backlogs eignet sich das Backlog Refinement Meeting. Die Aktualisierung des Product Backlogs wurde früher im deutschsprachigen Raum auch Backlog Grooming genannt.

Backlog Refinement Meeting¶

Obwohl das Backlog Refinement Meeting in der Abbildung „Anwesenheiten in Scrum Meetings" im vorherigen Kapitel genannt wird, ist dieses Meeting kein offizielles Scrum Event, das vom Scrum Guide vorgeschrieben wird. In der Praxis ist es aber durchaus sinnvoll, nicht auf dieses Meeting zu verzichten, denn dadurch kann das spätere Sprint Planning Meeting effizienter durchgeführt werden.

Wie der Name des Backlog Refinement Meetings schon sagt, wird hier der Product Backlog verfeinert und gepflegt. Das Scrum Team kommt zusammen und der Product Backlog wird gemeinsam betrachtet. Es werden vorhandene Einträge des Product Backlogs gesichtet sowie priorisiert. Während dieses Meetings werden zudem die Inhalte weiter spezifiziert und deren Aufwand abgeschätzt. Neue Einträge und User Stories ergeben sich aus den vorhergehenden Ergebnissen und Erkenntnissen. Die Priorisierung wird aufgrund sich ändernder Randbedingungen aktualisiert und Einträge oder User Stories, welche für das Produkt als unwichtig identifiziert wurden, werden aus dem Product Backlog entfernt.

Die folgenden Punkte können als Agenda für ein Backlog Refinement Meeting dienen:

• Ordnen und Priorisieren der Product-Backlog-Einträge
• Löschen von Product-Backlog-Einträgen, welche nicht mehr wichtig sind
• Hinzufügen von neuen Einträgen
• Ausformulieren und Hinzufügen von Details zu den PBIs
• Zusammenfassen von Product Backlog Items
• Schätzen von Product-Backlog-Einträgen (Aufwand)
• Eventuell Planung von Releases

Verantwortlich für das Backlog Refinement Meeting ist der Product Owner in seiner Rolle als Manager des Product Backlogs. Unterstützt wird er dabei von den Developern. Auf diese Art und Weise wird sichergestellt, dass der Product Owner den gleichen Kenntnisstand hat, wie die Developer. Des Weiteren wird durch diese Zusammenarbeit die Motivation des Teams gesteigert, da Zusammenhänge besser erkannt und unwichtige User Stories noch bevor sie unnötigerweise umgesetzt, werden aus dem Product Backlog entfallen.