| title | tags | author | anrechnung |
|---|---|---|---|
Product_Backlog |
agil klassisch |
PhilippWolfrum |
a |
Der Product Backlog ist bei Scrum die Liste aller Anforderungen für ein zu erstellendes Produkt1.
Bereits die Wahl der Bezeichnung "Backlog" (Auftragsbestand) weist darauf hin, dass das Product Backlog eine dynamische Liste ist und somit kein Lastenheft im traditionellen Sinn ist. Konsequent definiert der Scrum Guide den Product Backlog als Dokument des Product Lifecycle Managements und nicht als temporäres Projektdokument. Der Product Owner ist für das jeweilige Backlog verantwortlich, er muss Erweiterungen genehmigen, sowie Anforderungen für das Team priorisieren. Das Product Backlog enthält Eigenschaften, Funktionen, Anforderungen, Verbesserungen und Fehlerbehebungen, wobei jeder Eintrag mit Aufwandsschätzung, Beschreibung und Priorität versehen ist.1
Anforderungen aus dem Product Backlog werden im Sprint Planning in die jeweiligen Sprint Backlog gezogen und während eines Sprint bearbeitet.1.
Product-Backlog vs. Sprint-Backlog2
Wie erstelle ich die ersten Fassung des Scrum Product Backlogs? 3
Die erste Version wird oft auch als “Initial Product Backlog” bezeichnet, diese erste Fassung ist das Ergebnis der Kombination von Informationen aus verschiedenen Quellen:
- Die Produktvision: Von der ersten Produktvison können schon viele Product Backlog Items abgeleitet werden.
- Eine Product Roadmap: Sie legt Eckpunkte fest und gibt einen Rahmen wie das Product später genutzt werden soll.
- Das Minimum Viable Product (MVP): Ein MVP ist das minimale Produkt, mit dem eine Organisation dem Kundenwunsch entsprechen kann. Ein Scrumteam hat i.d.R. zuerst diese erste Produktversion im Blick. Denn anhand des MVP bekommt es Feedback auf sein Arbeitsergebnis.
- Stakeholder: Spätere Nutzer des zu entwickelnden Produktes sind die wichtigste Quelle für Input des Product Backlogs, sie wissen was sie benötigen oder stört. Wer das Scrum-Projekt gut angeht, hört genau zu, was die Stakeholder zu sagen haben.
- Das Entwicklerteam: Das Team arbeitet multidisziplinär, die Mitglieder sind Spezialisten auf ihrem Gebiet und haben das nötige Fachwissen. Sie steuern wertvolle Ergänzungen bei, sodass bei der Backlog Erstellung nichts vergessen wird.3
Wie sieht ein guter Product Backlog aus? 3
Ein guter Backlog zeichnet sich durch die vier Elemente "DEEP" aus:
- Detailed (detailliert): Items, die im nächsten oder übernächsten Sprint bearbeitet werden sollen, müssen „fertig für den Sprint“ sein. Gemeint ist damit, dass sie vom Entwicklerteam verstanden werden, klein genug sind und sowohl Akzeptanzkriterien als auch eine Definition of Done deutlich formuliert sind.
- Emergent (entwickelt sich nach und nach): Ein Product Backlog entwicklet sich im Verlauf des Projektes stetig weiter, vor dem ersten Sprint ist es dementsprechend noch nicht vollständig.
- Estimated (abgeschätzt): Die Items sind abgeschätzt, oftmals geschieht das in einer Planning Poker Session mittels Story Points.
- Prioritized (mit Prioritäten versehen): Der Product Owner hat die Items im Product Backlog mit Prioritäten versehen, sodass das Team anhand der Priorität das Sprint Planning füllen kann.3
Wie verbessere ich das Backlogs durch "Backlog Grooming"? 3
Bei Backlog Grooming (auch als Refinement bezeichnet) handelt es sich um ein Meeting, das kein fester Bestandteil des Scrum-Prozesses gemäß der Definition im Scrum Guide ist. In der Praxis hat sich diese Meeting jedoch als sehr wertvoll erwiesen. Gemeinsam mit dem Team schärft und bereitet der Product Owner die Backlog Items vor, die dann im nächsten Sprint Planning in den Sprint gezogen werden. Dabei werden folgende Schritte durchgeführt:
- User Stories gemäß neuester Erkenntnisse aktualisieren
- User Stories mit Prioritäten versehen
- Details in User Stories anbringen und sie aufteilen
- Abschätzen von User Stories durch das Entwicklerteam3
- Weiterfuehrende Literatur zum Thema z.B. Bücher, Webseiten, Blogs, Videos, Wissenschaftliche Literatur, ...