Scrum: Was ist ein Product-Backlog?
(Grafik: Shutterstock)
In Scrum gibt es neben dem Product-Backlog auch einen Sprint-Backlog. Beide sind klar voneinander zu differenzieren: Wie der Name schon sagt, hat der Sprint-Backlog lediglich für einzelne Sprints Relevanz, während der Product-Backlog während des gesamten Projektzeitraums gepflegt wird. Für beide Backlogs ist der Product-Owner verantwortlich.
Was ist im Product-Backlog enthalten?
Der Product-Backlog umfasst alles, um die Anforderungen an die zu entwickelnde Software zu erfüllen – also qualitative wie auch funktionale Anforderungen. Aber auch Bugs und benötigte Verbesserungen finden sich in der Liste. Häufig werden die durch User-Storys und Epics dargestellt. Wichtig ist, dass die Einträge, allgemein Product-Backlog-Items genannt, eine genaue Beschreibung, Priorität und Aufwandsschätzung – meist in Form von Story-Points – haben.
Du möchtest Scrum besser kennenlernen und verstehen? Unsere Videokurse zeigen dir, wie es geht!
Wie wird der Product-Backlog gepflegt?
Gerade am Anfang ist das Anlegen des Product-Backlogs aufwendig, da alle von dem Kunden vorgegebenen Anforderungen eingepflegt werden müssen. Aber auch nach dem Projektstart ist der Product-Backlog nicht in Stein gemeißelt, sondern verändert sich dynamisch. Der Product-Owner muss kontinuierlich über den gesamten Projektzeitraum hinweg den Backlog pflegen. Dazu zählt das Hinzufügen von neuen Anforderungen und aufgetretenen Bugs genauso wie das Bearbeiten oder Löschen von bestehenden Product-Backlog-Items – sollte das beispielsweise durch Kundenwünsche nötig werden. Wichtig ist auch, dass der Backlog absteigend nach der Priorisierung der einzelnen Aufgaben sortiert wird. Auch hier spielen die Wünsche des Kunden eine tragende Rolle. Je wichtiger für ihn eine Anforderung ist, desto weiter oben ist sie. Dann sollte die Anforderung aber auch detailliert beschrieben und der Aufwand geschätzt worden sein.
Wie viele Anforderungen gehören in den Sprint-Backlog? Dafür kann auf den Velocity-Faktor zurückgegriffen werden
Während der Sprint-Planung werden vor Beginn eines neuen Sprints durch das Entwicklungsteam und mithilfe der Empfehlungen des Product Owners die zu erledigenden Anforderungen aus dem Product-Backlog ausgewählt und in den Sprint-Backlog geschoben. Im Idealfall wird der vollständig bis zum Ende des Sprints von dem Scrum-Team abgearbeitet. Die Priorität und der Aufwand von Anforderungen, welche in den Product-Backlog-Items angegeben sind, spielen eine maßgebliche Rolle beim Anlegen eines neuen Sprint-Backlogs.
Mehr zu dem Thema aus dem Bereich Scrum liest du hier:
- Wie funktionieren Story-Points zur Aufwandsschätzung?
- Welche Aufgaben hat der Product Owner noch?
- Wie funktioniert die Sprint-Planung im Detail?
Hallo,
Der letzte Absatz des Artikels ist falsch. Nicht der Product Owner wählt die Sprint-Backlog-Items aus und verschiebt sie, sondern das Development Team. Welches (normalerweise in Zusammenarbeit mit dem PO) während des Sprint Planning-Meetings die Items aus dem Product Backlog auswählt und sich auf eine fertigzustellende Auswahl dieser Items innerhalb eines Sprints einigt. Dementsprechend ist das Development Team natürlich auch für das Sprint Backlog „verantwortlich“ (siehe erster Absatz).
Auch könnte man den zweiten Absatz und das Ende des dritten so verstehen, dass keine ungeschätzten Items im Product Backlog sind – dies ist nicht so. Es wird immer nur ein kleiner Teil der Product Backlog Items geschätzt, in o.g. Sprint Planning nämlich genau der Teil, der im nächsten Sprint bearbeitet wird (Refinements lassen wir hier der Einfachheit halber erstmal raus). Alles andere würde dem empirischen Gedanken von Scrum zuwiderlaufen (Inspection, transparency, adaption).
Und weil es so schön ist: Dass im Rahmen von Scrum hier so häufig „Projekt“ erwähnt wird, möchte ich etwas kritisieren. Scrum ist ein Werkzeugkasten, um komplexe Produkte(!) unter komplexen Bedingungen zu erstellen. Kleines Beispiel zur Verdeutlichung:
Ein Projekt hat einen festgelegten Start x und ein festgelegtes Ende y. Das hat irgendwann mal irgendwer so festgelegt. Mit seiner Glaskugel.
Schon allein diese Annahme deckt sich nicht mit inspect/adapt. Ein mit Scrum entwickeltes Produkt braucht so lange, wie es eben dauert, da ja gerade die kurzen Feedbackzyklen oft dazu führen, dass einige Features wieder entfernt werden, oder gnaz neue hinzukommen, wenn der Bedarf dafür entdeckt wird.
Es wäre generell einfach schön, wenn solche Artikel es nicht durch ein inhaltliches Lektorat schaffen und dann auch noch auf Platz 1 der Startseite auftauchen. Danke.
Schöne Grüße,
Dominik
Die Aussagen zum Sprintbacklog stimmen leider nicht. Es wird nicht durch den PO bestimmt, sondern obliegt der Hoheit des Entwicklungsteams, da das Sprintbacklog den Plan widerspielt, was das Team in den nächsten Iteration umsetzen will bzw. kann. Natürlich findet ein gemeinsames Palnning statt wobei das prioriserte Backlog des POs die Grundlage darstellt. Der PO schiebt also nicht, sondern das Entwicklungsteam zieht.
Hallo Rainer,
ja da hast du Recht. der PO ist nur beim Planning dabei – am Ende entscheidet aber tatsächlich nur das Entwicklungsteam. Wird im Artikel behoben.
Viele Grüße,
Andreas