Scrum: Wer erstellt Produkt-Backlog-Elemente oder Benutzerstories?

Diese Frage ist komplexer, als sie auf den ersten Blick erscheint. Zunächst kann man sagen, dass Produkt-BacklogElemente können Anwendungsfälle, Epics, Benutzerstories, sogar Fehler oder zeitlich begrenzte Forschungsaufgaben im Produkt-Backlog enthalten.

In der einfachsten Definition ist das ScrumProdukt-Backlog ist einfach eine Liste aller Produkt-Backlog-Elemente (PBIs), die im Projekt abgeschlossen werden müssen. Es ersetzt die traditionellen Anforderungsspezifikationen Artefakte. PBIs spiegeln die Bedürfnisse von Kunden oder Stakeholdern wider. Eine gängige Methode, Endbenutzeranforderungen zu erfassen, besteht darin, PBIs in Form von Benutzerstories.

Wer ist für die Pflege des Produkt-Backlogs verantwortlich?

Der Produktverantwortliche (PO) „besitzt“ das Produkt-Backlog im Namen der Stakeholder und ist hauptsächlich für seine Erstellung verantwortlich. Der PO muss das Backlog nicht persönlich erstellen—er oder sie kann an das Entwicklungsteam und/oder Scrum Masterableiten, um Backlog-Elemente zu definieren und abzuschätzen. Der PO ist für die Erstellung und Pflege des Produkt-Backlogs verantwortlich. Daher überwacht der PO auch den Backlog-RefinementProzess.

Das Produkt-Backlog entspricht Ihrem Projektroadmap – dem Plan, den das Team liefern möchte. Nachdem das Team es definiert hat, priorisiert es, welche Funktionen und Anforderungen gebaut werden sollen. Das Produkt-Backlog dient auch als Repository, das alle Informationen enthält, die das Team zur Verfolgung und zum Austausch benötigt.

Ist ein Produkt-Backlog-Element dasselbe wie eine Benutzerstory?

Wie erwähnt, spiegeln PBIs die Bedürfnisse von Kunden oder Stakeholdern wider. Eine gängige Methode, Endbenutzeranforderungen zu erfassen, besteht darin, PBIs in Form von Benutzerstories. Allerdings können PBIs auch Anwendungsfälle, Epics, Benutzerstories, Fehler oder zeitlich begrenzte Forschungsaufgaben im Produkt-Backlog enthalten. In der Realität befinden sich nicht alle Elemente im Produkt-Backlog auf der gleichen Detailstufe, wie in der Abbildung unten gezeigt:

Detailliertes Produkt-Backlog

PBIs, die wir bald bearbeiten möchten, sollten nahe an der Spitze des Backlogs stehen, kleiner in Größe und sehr detailliert sein, damit sie in kurzer Zeit bearbeitet werden könnenSprint. PBIs, die wir eine Weile nicht bearbeiten werden, sollten am Ende des Backlogs stehen – größer, weniger detailliert. Das ist in Ordnung; wir planen nicht, diese Artikel in absehbarer Zeit zu bearbeiten.

Wenn wir uns der Bearbeitung größerer PBIs, wie Epics, nähern, zerlegen wir sie in eine Reihe kleinerer, sprintbereiter Geschichten. Dies sollte rechtzeitig erfolgen. Wenn wir zu früh verfeinern, könnten wir Zeit verschwenden, um Details zu klären, die nie umgesetzt werden. Wenn wir zu lange warten, blockieren wir die PBIs, die in den Sprint fließen sollen, und verlangsamen das Team. Wir müssen das richtige Gleichgewicht zum richtigen Zeitpunkt finden.

Agiles priorisiertes Produkt-Backlog

Wer ist für die Verfeinerung von PBIs verantwortlich?

Der Product Owner (PO), der das Produkt-Backlog im Namen der Stakeholder „besitzt“, ist hauptsächlich für die Erstellung und Pflege verantwortlich. Der PO muss nicht jedes Backlog-Element persönlich erstellen – er oder sie kann das Entwicklungsteam und/oder den Scrum Master einbeziehen, um Items zu definieren und abzuschätzen. Der PO überwacht den gesamten Prozess der Backlog-Verfeinerung.

Daher, um die Frage zu beantworten: Der Product Owner besitzt das Produkt-Backlog, muss aber nicht jedes Backlog-Element erstellen. Typischerweise erstellt der Product Owner große PBIs auf Basis von hochrangigen Anforderungen oder Nutzerzielen und delegiert dann an das Team, um diese großen Items in Nutzerstories zu zerlegen. Diese kleineren Geschichten – geeignet für die Spitze des Backlogs und entsprechend den Kriterien von „Bereit“ (normalerweise unter der Definition von Bereit) – werden dann in das Sprint-Backlog.