Product Backlog

Das Produkt Backlog ist eine Aufschlüsselung der zu erledigenden Arbeit. Welches auch eine geordnete Liste der Produktanforderungen enthält, welches ein Scrum-Team für ein Produkt pflegt. Zu den üblichen Formaten gehören User Stories und Use Cases. Die Anforderungen definieren Funktionen, Fehlerbehebungen, nicht-funktionale Anforderungen usw. – alles, was zu tun ist, um ein brauchbares Produkt zu liefern. Der Product Owner priorisiert die Product Backlog Items (PBIs). Dies auf der Grundlage von Überlegungen wie Risiko, Geschäftswert, Abhängigkeiten, Größe und dem Zeitraum der Umsetzung.

Der Product Backlog enthält das, was zu liefern ist und in welcher Reihenfolge es zu liefern ist. Es ist für jedermann sichtbar, kann aber nur mit Zustimmung des Product Owners geändert werden. Dieser ist letztendlich für die Bestellung der Product Backlog Items verantwortlich, die das Entwicklungsteam auswählen kann.

Der Product Backlog enthält die Einschätzung des Product Owners zum Geschäftswert und die Einschätzung des Entwicklungsteams zum Entwicklungsaufwand, die oft, aber nicht immer, in Story Points unter Verwendung der gerundeten Fibonacci-Skala angegeben werden. Diese Schätzungen helfen dem Product Owner, den Zeitrahmen abzuschätzen, und können die Bestellung von Produkten im Auftragsbestand beeinflussen; wenn beispielsweise zwei Merkmale den gleichen Geschäftswert haben, kann der Produkteigentümer eine frühere Lieferung des Merkmals mit dem geringeren Entwicklungsaufwand oder des Merkmals mit dem höheren Entwicklungsaufwand planen.

Das Product Backlog und der Geschäftswert jedes Product Backlog-Items liegt in der Verantwortung des Product Owners. Der Aufwand für die Auslieferung jedes Items wird vom Entwicklungsteam in Story Points oder Zeit geschätzt. Durch die Schätzung in Story Points verringert das Team die Abhängigkeit von einzelnen Entwicklern. Das ist besonders in dynamischen Teams nützlich, in denen Entwickler nach dem Sprint oft anderen Projekten zugeteilt werden. Wenn z. B. eine User Story mit einem Wert von 5 im Aufwand geschätzt wird (unter Verwendung der Fibonacci-Folge), bleibt sie 5, unabhängig davon, wie viele Entwickler an ihr arbeiten.

Story Points definieren den Aufwand in einer Timebox, so dass sie sich mit der Zeit nicht ändern. Zum Beispiel kann eine Person in einer Stunde gehen, laufen oder klettern, aber der Aufwand ist deutlich unterschiedlich. Die Lückenprogression zwischen den Begriffen in der Fibonacci-Folge ermutigt das Team, sorgfältig überlegte Schätzungen abzugeben. Schätzungen von 1, 2 oder 3 implizieren ähnliche Anstrengungen (1 ist trivial), aber wenn das Team eine 8 oder 13 (oder höher) schätzt, kann die Auswirkung sowohl auf die Durchführung als auch auf das Budget erheblich sein. Der Wert der Verwendung von Story Points liegt darin, dass das Team diese wiederverwenden kann, indem es ähnliche Arbeiten aus früheren Sprints vergleicht, aber es sollte berücksichtigt werden, dass Schätzungen relativ zum Team sind. Beispielsweise könnte eine Schätzung von 5 für ein Team eine 2 für ein anderes mit leitenden Entwicklern und höheren Fähigkeiten sein.

Der Produkt-Backlog…

Typischerweise arbeiten der Product Owner und das Scrum-Team zusammen, um die Aufschlüsselung der Arbeit zu entwickeln. Welches zum Product Backlog wird, das sich als neue Informationsflächen über das Produkt und über seine Kunden entwickelt. Dadurch können sich spätere Sprints mit neuer Arbeit befassen.

Hier finden Sie eine Übersicht unserer Scrum Ausbildung mit offizieller Scrum Zertifizierung der ICO oder wahweise vom TÜV.