Product Backlog
Das Product Backlog ist ein wichtiger Bestandteil von Scrum. Es handelt sich dabei um eine Liste mit den priorisierten Anforderungen eines Projekts. In dieser Liste wird aufgeführt, wie komplex die einzelnen Anforderungen im Vergleich zueinander sind. Üblicherweise wird das Product Backlog sukzessive nach absteigender Priorität abgearbeitet. Allerdings wird die Prioritätenliste kontinuierlich während der Projektarbeit aktualisiert, sodass sich auch eine Verschiebung der Prioritäten ergeben kann.
Inhalte des Product Backlogs
Das Product Backlog wird durch den Product Owner bei Scrum angelegt, entwickelt, gepflegt und geändert. Es enthält alle Anforderungen des Projekts. Im Zentrum der Betrachtung stehen hier weniger die technischen Aspekte, sondern mehr die Bedürfnisse der späteren Nutzer. Das Product Backlog enthält in der Regel sogenannte „User Stories“.
Üblicherweise formuliert man bei Softwareprojekten Aufgabenpakete, beispielsweise „Erstellung einer Funktion zur Hinterlegung eines Kommentars bei Kundenbestellungen“. Im Product Backlog hingegen würde dies in Form einer User Story folgendermaßen formuliert, die beispielsweise so aussehen könnte: „Sachbearbeiter Müller möchte im hektischen Alltag nicht vergessen, dass er mit Kunde Maier für bestimmte Fälle Sonderkonditionen vereinbart hat, um ihn nicht mit falschen Rechnungen zu verärgern“.
Genauigkeit der Einträge
Anfänglich ist das Product Backlog nicht besonders ausführlich. Es enthält lediglich grob die wichtigsten Anforderungen an das Endergebnis. Beginnt das Team mit der Arbeit, dröselt der Product Owner das Produkt in verschiedene Teilanforderungen auf und konkretisiert diese in genaueren User Stories. Je näher die Abarbeitung einer User Story rückt, desto detaillierter wird sie in einzelne Teilstories aufgeteilt.
Im Sprint Planning Meeting treffen sich Product Owner und das Team. Der Product Owner gibt vor, welche User Story als nächstes angegangen werden soll. Das Team entscheidet daraufhin, welche Teilaufgaben auf welche Mitarbeiter verteilt werden sollen. Die User Stories im Product Backlog müssen so klein aufgegliedert werden, dass das Team diese innerhalb eines Sprints abarbeiten kann. Ein Sprint dauert erfahrungsgemäß zwischen einer und vier Wochen, je nach anfänglicher Definition durch den Scrum Master.
Priorisierung
In Bezug auf das Product Backlog spielt die Priorisierung eine wichtige Rolle. Alleine der Product Owner ist dazu ermächtigt, die Priorisierung innerhalb des Product Backlogs vorzunehmen. Die Priorisierung entscheidet darüber, was im nächsten Sprint zu bearbeiten ist. Während eines laufenden Sprints darf der Product Owner die Priorisierung nicht einfach rückwirkend ändern, also beispielsweise die laufenden Arbeiten an einer User Story abbrechen, auf später verschieben und eine andere User Story vorziehen.
Unabhängig vom laufenden Sprint werden die Priorisierungen, auch in Absprache mit den Stakeholdern, ständig korrigiert und angepasst. Dabei spielen Aspekte wie die Dringlichkeit bzw. Notwendigkeit, die Größe des wirtschaftlichen Nutzens oder die Höhe des Risikos eine große Rolle. Um den Überblick und die Kontrolle über alle durchzuführenden Aufgaben zu behalten, hilft ein Sprint Backlog, eine Liste mit allen Aufgaben des gesamten Projektes.
Aufwandsschätzung
Für jeden Eintrag im Product Backlog sollte eine grobe Schätzung bezüglich des Arbeitsaufwands vorgenommen werden. Je näher eine User Story rückt, desto genauer sollte diese Aufwandsschätzung ausfallen. Häufig wird hier zwischen dem besten und dem schlimmsten Fall unterschieden, um unvorhergesehene Schwierigkeiten einzukalkulieren und Zeitverzögerungen zu vermeiden.
Nutzen für das Development
Ein Product Backlog kann Agenturen die Bearbeitung von Kundenaufträgen erleichtern. Voraussetzung für die konsequente Anwendung ist die Projektmanagement-Methode Scrum. Damit die Projektarbeit erfolgreich wird, müssen jedoch der Product Owner und das Team ihre Aufgaben zuverlässig ausführen. Ein Vorteil von Product Backlogs im Online-Marketing besteht darin, dass die Methode sehr flexibel auf sich verändernde Umstände reagiert. Wenn sich zum Beispiel nach der Auswertung einer Kampagne die Zielsetzungen ändern, können diese durch Anpassung der User Story schnell in den Product Backlog integriert und die Priorisierung modifiziert werden.
Weblinks