Das Scrum Product Backlog ist einer der wichtigsten Bestandteile eines jeden Scrum-Projektes. Sind Sie Product Owner, und von Ihnen wird erwartet, dass Sie ein Product Backlog erstellen? Oder sind Sie Scrum Master, und der Product Owner hat Sie gebeten, in Sachen Product Backlog Hilfestellung zu leisten? Dann werden Sie in diesem Blogartikel einige praktische Dinge erfahren, die Sie sich zunutze machen können.
Wenn Sie diesen Beitrag gelesen haben, wissen Sie, wie Sie vom Anfang Ihres Scrum-Projekts bis zu seinem Ende mit dem Product Backlog umgehen sollten.
Der Artikel beantwortet die folgenden Fragen:
- Wie erstellen Sie die erste Fassung des Product Backlog?
- Wie sieht ein gutes Product Backlog aus?
- Wie setzen Sie als Product Owner Prioritäten?
- Was ist Backlog Grooming?
- Wann ist das Product Backlog bereit für das Sprint Planning?
- Wo finden Sie ein Template für ein Product Backlog?
Wie erstellen Sie die erste Fassung des Scrum Product Backlog?
Die erste Version davon wird oft auch als “Initial Product Backlog” bezeichnet. Diese erste Fassung ist das Ergebnis der Kombination von Informationen aus verschiedenen Quellen:
- Die Produktvision: Ein guter Product Owner hat vorab eine Produktvision definiert. Von ihr alleine schon kann er viele Product Backlog Items ableiten.
- Eine Product Roadmap: Wenn ein bestehendes Produkt weiterentwickelt werden soll, gibt es oft eine Product Roadmap. Ein gutes Beispiel sind das iPhone 4, 5, 6, 7 usw. Die Roadmap liefert Input für das Product Backlog.
- Das Minimum Viable Product (MVP): Ein MVP ist das minimale Produkt, mit dem eine Organisation dem Kundenwunsch entsprechen kann. Ein Scrum Team hat i.d.R. zuerst diese erste Produktversion im Blick. Denn anhand des MVP bekommt es Feedback auf sein Arbeitsergebnis.
- Stakeholder: Benutzer und Käufer des zu entwickelnden Produktes sind vielleicht die wichtigste Quelle für Input für das Product Backlog. Sie können genau angeben, was sie benötigen. Wer das Scrum-Projekt gut angeht, hört genau zu, was die Stakeholder zu sagen haben.
- Das Entwicklungsteam: Viele Scrum-Projekte erfordern viel Fachwissen. Deshalb wird in multidisziplinären Teams gearbeitet. Seine Mitglieder sind Spezialisten auf ihrem Gebiet. Auch sie liefern oft wertvolle Ergänzungen für das Product Backlog, die ein Product Owner oder auch Stakeholder schnell vergessen würden.
All diese Quellen zusammen genommen bilden einen umfassenden Ausgangspunkt für die Definition von User Stories, mit denen Sie anfangen können.
Wie sieht ein gutes Product Backlog aus?
Ein gutes Backlog zeichnet sich durch vier Elemente aus. Eine praktische Eselsbrücke: Ein gutes Product Backlog ist „DEEP“. Das sind die Anfangsbuchstaben der vier Elemente:
- Detailed (detailliert): ein gutes Backlog besteht aus genügend Backlog Items (User Stories), um mindestens einen Sprint zu füllen. Im Idealfall reichen die Items für zwei Sprints. User Stories mit einer niedrigeren Priorität brauchen nicht allzu detailliert dargestellt zu werden. Items, die in Kürze angegangen werden sollen, müssen jedoch „fertig für den Sprint“ sein. Damit ist gemeint, dass das Entwicklerteam die Items genau versteht, sie klein sind und die Akzeptanzkriterien sowie eine Definition of Done deutlich definiert sind.
- Emergent (entwickelt sich nach und nach): Ein Product Backlog wird im Verlauf des Projektes (gemeinsam) nach und nach entdeckt. Vor dem ersten Sprint streben wir also nicht nach einem vollständigen Backlog. Stärker noch: Wir wissen es eben gerade zu schätzen, wenn noch kein vollständig ausgearbeiteter Plan vorliegt.
- Estimated (abgeschätzt): Die User Stories sind abgeschätzt. Oft geschieht das in einer Planning Poker Session mittels Story Points.
- Prioritized (mit Prioritäten versehen): Die User Stories im Product Backlog hat der Product Owner mit Prioritäten versehen. Die untenstehenden Faktoren sind bei der Priorisierung durch den Product Owner entscheidend.
Was ist „Backlog Grooming“?
Bei Backlog Grooming (manchmal auch als Backlog Refinement bezeichnet) handelt es sich um ein Meeting, das kein fester Bestandteil des Scrum-Prozesses gemäß der Definition im Scrum Guide ist. Tatsächlich hat sich dieses Meeting in der Praxis aber als eines der wertvollsten erwiesen. Denn in ihm wird das Product Backlog für das nächste Sprint Planning Meeting vorbereitet. Eine Backlog Grooming Session wird mit dem Entwicklungsteam abgehalten:
- User Stories gemäß neuester Erkenntnisse aktualisieren
- User Stories mit Prioritäten versehen
- Detail in User Stories anbringen und sie aufteilen
- Abschätzen von User Stories durch das Entwicklerteam
Product Backlog Grooming fällt unter die Verantwortlichkeit des Product Owners. Denn der Product Owner ist für das Product Backlog zuständig. Aber auch vom Entwicklungsteam wird Input benötigt. Manchmal wird ein Teil des Entwicklungsteams an dem Prozess beteiligt. Der Product Owner reserviert während des Sprints 10% ihrer oder seiner Zeit für das Grooming.
