Das Product Backlog ist ein Bestandteil von Scrum. Es besteht aus einer Liste von priorisierten Anforderungen an ein Projekt. Das Produckt Backlog wird vom Product Owner angelegt, geänder, gepflegt und entwickelt, Hier geht es weniger um die technischen Aspekten, sondern vielmehr um die Bedürfnisse des späteren Nutzers die man mit User Stories umschreibt.
Für das Spring Planning treffen sich Product Owner und Team, Der Product Owner gibt vor welche Story als nächstes umgesetzt wird und im Team werden die Teilaufgaben selbstorganisiert verteilt die in einem Sprint abgearbeitet werden. Dieser dauert bis zu 4 Wochen. Der Product Owner ist allein dazu berechtigt Einträge des Product Backlogs zu priorisieren. Jeder Eintrag im Product Backlog wird vom Aufwand her geschätzt.
Items des Product Backlogs können sein:
- User Stories
- Qualitätsanforderungen
- Fehler (Bugs) die behoben werden müssen
- Funktionale Anforderungen
- Verbesserungen
Die Listeneinträge des Product Backlogs werden priorisiert, geschätzt in ihrem Aufwand, bewertet bezüglich des Kundennutzens, je weiter oben sie stehen, desto detaillierter werden sie ausgearbeitet, sie unterliegen einer Dynamik der ständigen Weiterentwicklung und Verfeinerung auch können vorhanden Einträge wieder entfernt werden und neue hinzu kommen.
Einträge des Product Backlogs werden anhand ihrer Wirtschaftlichkeit, dem Verhältnis von Kosten und Nutzen priorisiert. Hier spielen auch Costs of Delay, also Verzögerungskosten eine Rolle, je länger eine Aktivität hinaus gezögert wird, um so mehr Kosten verursacht sie.
Mit Hilfe von User Stories können Einträge des Product Backlogs geschrieben werden. Hierbei hilft es den folgenden Satz zu vervollständigen „Als______ möchte ich _______, damit ______.“
Einträge des Product Backlogs die den Status ready haben können in den Sprint Backlog aufgenommen werden. So können Einträge work in progess sein und am Ende done.
Dabei entscheidet der Product Owner allein, wann ein Item tatsächlich als done gekennzeichnet werden kann.
Während des Sprints entsteht ein auslieferbares Produktinkrement aus dem Sprint Backlog
Das Entwicklungsteam zieht Arbeit in den Sprint und erstellt einen Forecast (wie eine Wetterwohersage, die nicht immer stimmen muss) darüber, wie viel es schaffen kann
0 Kommentare
Hast du eine Frage oder ein Praxisbeispiel? Teile es mit uns.