Ratgeber

Scrum: Was ist ein Product-Backlog?

(Grafik: Shutterstock)

Der Product-Backlog ist eine dynamische Liste, in der alle Software-Anforderungen gesammelt werden. So wird mit ihr in Scrum gearbeitet.

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.

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:

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

3 Kommentare
Dominik Guhr

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

Antworten
Rainer Pabst
Rainer Pabst

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.

Antworten
Andreas Domin

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

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung