Product Backlog

Der Produkt Backlog ist eine Aufschlüsselung der zu erledigenden Arbeit und enthält eine geordnete Liste der Produktanforderungen, die 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 getan werden muss, um ein brauchbares Produkt zu liefern. Der Product Owner priorisiert die Product Backlog Items (PBIs) auf der Grundlage von Überlegungen wie Risiko, Geschäftswert, Abhängigkeiten, Größe und dem Zeitraum der Umsetzung.

Der Product Backlog ist das, was geliefert wird, bestellt in der Reihenfolge, in der es geliefert werden soll. Er ist für jedermann sichtbar, kann aber nur mit Zustimmung des Product Owners geändert werden, der letztendlich für die Bestellung der Product Backlog Items verantwortlich ist, die das Entwicklungsteam auswählen kann.

Definition: Scrum Product Backlog
Definition: Scrum Product Backlog

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.

Der 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.

Zusammenfassung

Der Produkt-Backlog…

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

Weitere Einträge