Product Backlog : Definition
Das Scrum Handbuch in Scrum definiert das Product Backlog als „eine geordnete Liste dessen, was zur Verbesserung des Produkts benötigt wird“. Xavier Koma gibt eine noch präzisere Definition, die besagt, dass es sich um eine geordnete Liste aller Funktionalitäten/Elemente handelt, unabhängig von der Form oder dem Format des Elements, das eine User Story, eine Spezifikation, ein Briefing, ein Powerpoint-Modell oder eine Gurke sein kann. Die einzige Bedingung ist, dass sich das Team auf das Format einigt, um die gleiche Kommunikation und das gleiche Verständnis zu erhalten.
Unterschiede zwischen book of specification und Product Backlog
Wer ist für das Product Backlog verantwortlich?
Der Product Owner ist für das Backlog verantwortlich und definiert es in der Regel zusammen mit dem Team, das an den User Stories arbeitet, damit diese von den Entwicklern unterstützt werden können. Es kann sein, dass das Entwicklungsteam die User Story aus technischer Sicht entwirft, aber es ist immer der Product Owner, der die Prioritäten der Elemente festlegen muss.
Was sind die Merkmale eines Product Backlogs?
Das Produkt-Backlog hat einige Hauptmerkmale. Claude Aubry fasste sie mit dem Akronym „prouvé“ (bewährt, getestet) zusammen:
- Öffentlich (publique): Die gesamte Organisation muss Zugang zum Product Backlog haben, es ist eine Frage der Sichtbarkeit und Ausrichtung.
- Reduziert (réduit) : Das Produkt-Backlog muss sehr kurz sein, im Allgemeinen zwischen 40 und 60 Artikeln.
- Sortiert (Ordonné): Die Elemente werden in absteigender Reihenfolge sortiert, d. h. das Element mit dem höchsten Wert steht oben. Der Product Owner kann verschiedene agile Techniken anwenden, um das Backlog zu ordnen.
- Einzigartig (unique): nur ein Product Backlog pro Produkt!
- Lebendig (vivant): Der Product Owner kann das Product Backlog nach Belieben entsprechend den entstehenden Bedürfnissen des Produkts neu anordnen.
- Aufsteigend (émergent): Das Backlog ist nie vollständig, es ändert sich ständig und es ist immer möglich, neue Elemente oder neue Funktionalitäten hinzuzufügen.
Wie baut man einen Backlog? Welche sind die Etappen?
Source : Eden tech labs
Das Product Backlog ist ein wichtiges Artefakt der Scrum-Methodik(no link su ge) und das Hauptarbeitsmittel des Product Owners. Hier sind die 5 wichtigsten Schritte, um einen Auftragsbestand effektiv zu verwalten:
- Identifizierung der Bedürfnisse
- Anwenderberichte schreiben
- Priorisierung des Product Backlogs
- Überprüfung des Qualitätsniveaus der User Stories
- Akzeptanzkriterien hinzufügen
Identifizieren Sie den Bedarf
Zunächst muss die Vision des Projekts festgelegt werden, d. h. es muss klar definiert werden, welches Ziel mit dem Projekt erreicht werden soll, und es müssen die verschiedenen beteiligten Parteien ermittelt werden. Es ist wichtig, dass diese Vision von allen akzeptiert und verstanden wird und dass die Beteiligten ihr zustimmen, da das Team gemeinsam mit dem Product Owner das Projekt entsprechend der Zielsetzung durchführen muss.
User story schreiben
Dann ist es an der Zeit, die User Stories zu schreiben und dabei einige grundlegende Fragen zu klären: Welche Funktionalität soll erstellt werden? In welcher Reihenfolge sollen sie geliefert werden? Für wen sind sie bestimmt?
Das Product Backlog kann nach verschiedenen Kriterien organisiert werden:
- Themen: logische Gruppierung einer vom Product Owner festgelegten Anzahl von Themen. Es gibt keine absolute Regel, wichtig ist nur, dass die Organisation optimal ist. Diese Themen werden dann nach Merkmalen untergliedert.
- Feature: Gruppierung von User Stories. Jedes Merkmal stellt einen großen Funktionsblock dar, d. h. eine wichtige Funktionalität des Produkts. Diese Funktionen werden in Elemente unterteilt, die auch User Stories genannt werden.
- User story: Benutzergeschichten oder Elemente oder Aktivitäten oder Backlog-Elemente sind verschiedene Arten der Definition von Verbesserungen, Entwicklungen, Funktionalitäten, Funktionen oder Fehlern.
- Teilaufgaben: Das Entwicklungsteam, zum Beispiel in Scrum, unterteilt die Menge der Elemente während der Sprintplanung in technische Teilaufgaben oder sogar in anormale Teilaufgaben.
Was also bedeutet EPIC?
Die Definition von „EPIC“ ist nicht eindeutig: In einer SAFe-Umgebung ist es beispielsweise die erste Ebene, die sogar dem Thema vorausgeht und auf der Makroebene bleibt.
Einerseits kann EPIC auf der gleichen Ebene liegen wie ein Feature oder ein Thema, aber im Grunde genommen ist die ursprüngliche Definition von EPIC die einer großen Geschichte, eines Bedürfnisses, mit geringer Sichtbarkeit. Dieses berühmte EPIC gliedert sich in mehrere User Stories. Anschließend sprechen wir über die Reifung von EPIC zu einer User Story.
Es gibt mehrere mögliche Bedeutungen, wobei die wichtigste ist, dass das Team seine eigene Definition festlegt, an der sich alle orientieren müssen.
Priorisierung des Product Backlog
Wenn der Product Owner das Product Backlog priorisieren muss, stößt er oft auf ein häufiges Problem: einen vagen und inkonsistenten Priorisierungsprozess. Als Product Owner erhalten Sie täglich Kommentare, neue Ideen und Funktions Anfragen von verschiedenen Interessengruppen, und natürlich können Sie es nicht allen recht machen.
Die Betroffenen sind möglicherweise verwirrt darüber, dass Sie einigen Punkten Vorrang vor anderen gegeben haben, und haben das Gefühl, dass sie keinen ausreichenden Einfluss auf Ihren Priorisierungsprozess haben.
Ein wichtiger Schritt zur Lösung dieser Probleme ist die Standardisierung des Priorisierungsprozesses. Hierfür gibt es verschiedene Techniken:
- Moscow
- Wert vs. Aufwand
- ICE
- REIS
- WSJF
Diese Techniken ermöglichen ein reproduzierbares, transparenteres und weniger zufälliges Vorgehen bei der Prioritätensetzung.
Überprüfen Sie das Qualitätsniveau der User Stories
Product Backlog Refinement, auch bekannt als Backlog Grooming, ist eine Scrum-Praxis, die, wie der Name schon sagt, darauf abzielt, den Inhalt des Product Backlogs zu verfeinern. Es ist ein idealer Zeitpunkt, um die Qualität einer User Story gemeinsam mit dem gesamten Team zu überprüfen und zu hinterfragen. Dank des Inputs aller Beteiligten kann der Product Owner die für den Sprint ausgewählten User Stories verbessern.
Vor dem Start einer Interaktion (Zyklus von 1 bis 4 Wochen) müssen der Product Owner und sein Team sicherstellen, dass die User Stories von einer Person und innerhalb einer Iteration erreicht werden können.
Akzeptanzkriterien hinzufügen
Um die User Stories zu optimieren, muss das Team während des Backlog Refinement Meetings gemeinsam die Akzeptanzkriterien einer User Story definieren, die es erlauben zu überprüfen, ob sie als „erledigt“ realisiert werden kann.
Die Definition von Done (DoD) ist die Qualität des gelieferten Produkts. Es handelt sich um eine Liste von Kriterien, anhand derer entschieden wird, ob eine Funktionalität als „fertig“ betrachtet und am Ende des Sprints geliefert werden kann. Sie ist auf alle Rückstände anwendbar.
Die Geschwindigkeit eines Teams basiert auf den „fertigen“ Funktionalitäten. Es ist ein Vertrag zwischen dem Team und dem Product Owner (der die beteiligten Parteien vertritt und die Stimme des Kunden ist) und definiert klar die Kriterien, die erfüllt sein müssen, damit eine User Story, eine Iteration oder eine Version fertiggestellt und ausgeliefert werden kann.
Eine erste Version des Backlogs muss unbedingt vor dem ersten Sprint definiert werden, um die Entwicklungen zu organisieren, da das Product Backlog auch als Planungsinstrument dient. Abhängig von der Geschwindigkeit des Arbeitsteams (berechnet im Story Point), werden Sprints erstellt und mit den im Story Point geschätzten User Stories geladen. Im Laufe der Sprints wird das Backlog mit neuen Epics angereichert, die einem neu identifizierten Bedarf, neuen US, die eine bereits entwickelte Funktion vervollständigen, Bugs oder technischen Aufgaben entsprechen, um technische Schulden des Produkts zu vermeiden.
Welche Tools können für die Verwaltung eines Product Backlogs verwendet werden?
Ein Product Backlog kann mit einer einfachen Excel-Tabelle erstellt werden, aber einige Tools erleichtern die Verwendung und Fortführung von User Stories, darunter JIR, Trello und Projectboard.
