Was ist ein Product Backlog in Scrum? Wer besitzt es?

Product Backlog ist die einzige Quelle der Wahrheit für alles, was im Produkt benötigt wird, und eine priorisierte Liste von Änderungen an Produktanforderungen. Der Product Owner ist für den Inhalt, die Verfügbarkeit und die Priorisierung der Product-Backlog-Elemente verantwortlich.

Das Product Backlog ist eine sich entwickelnde Liste. Die erste Version listet nur die ersten und am besten bekannten Anforderungen auf (keine Notwendigkeit, sie gründlich zu verstehen). Das Product Backlog entwickelt sich weiter, je nachdem, wie sich das Produkt und die Entwicklungslandschaft verändern. Es ist dynamisch und ändert sich häufig, um festzustellen, was notwendig ist, um das Produkt lebensfähig, wettbewerbsfähig und nützlich zu machen. Solange das Produkt existiert, existiert auch das Product Backlog.

Das Product Backlog listet alle Funktionen, Anwendungsfälle, Benutzerstories, Verbesserungen und Fehlerbehebungen auf, die für zukünftige Releases geplant sind. Ein Product-Backlog-Element (PBE) enthält Beschreibung, Reihenfolge und geschätzten Aufwand.

Product-Backlog-Elemente (PBEs) werden typischerweise nach Wert, Risiko, Priorität und Notwendigkeit geordnet. Sie sind von höchster bis niedrigster Priorität geordnet, wobei jedes Element eine eindeutige Reihenfolge hat. Die obersten Elemente im Product Backlog müssen unmittelbar entwickelt werden. Je höher die Rangfolge, desto dringender das Element, und desto sorgfältiger müssen Sie dessen Wert berücksichtigen – Ihr Verständnis von Wert wird konsistenter.

Scrum-Product-Backlog

Höher bewertete Elemente im Product Backlog sind klarer und spezifischer als niedriger bewertete. Diese Elemente können aufgrund klarer Inhalte und detaillierterer Informationen genauer geschätzt werden. Mit anderen Worten: Je niedriger die Priorität eines Backlog-Elements, desto weniger detailliert wird es. Die Product-Backlog-Elemente, die das Team in einem Sprint sind fein granuliert und in kleinere Aufgaben aufgeteilt, sodass jedes Element innerhalb des Timebox. Product-Backlog-Elemente, die das Entwicklungsteam in einem Sprint „abschließen“ kann, gelten als die **Definition von „Ready“** erfüllt und können während des Sprint-Planungstreffen.

Scrum-Prozess

Sobald das Produkt bereitgestellt wird, wird der Wert realisiert und das Marktfeedback nimmt zu, wodurch das Product Backlog größer und detaillierter wird. Da Anforderungen niemals aufhören, sich zu ändern, ist das Product Backlog ein lebendiges Artikel. Änderungen in den Geschäftsanforderungen, Marktbedingungen und Technologie können Änderungen im Product Backlog verursachen.

Während mehrere Scrum-Teams können zusammenarbeiten, um ein Produkt zu entwickeln, beschreibt jedoch nur ein einziges Product Backlog die nächste Arbeit für das Produkt. Anschließend müssen Sie Attribute verwenden, um Product-Backlog-Elemente zu kategorisieren.

Durch Product-Backlog-Verfeinerung, werden Details, Schätzungen und Reihenfolge hinzugefügt. Dies ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam zusammenarbeiten, um die Details jedes Backlog-Elements zu besprechen. Die Elemente werden im Product Backlog überprüft und überarbeitet. Der Product Owner kann jedoch zu jeder Zeit ein beliebiges Element im Product Backlog aktualisieren und Entscheidungen treffen, wenn nötig.

Product-Backlog-Verfeinerung ist eine fortlaufende Tätigkeit – keine zeitlich begrenzte –, die vom Product Owner und dem Entwicklungsteam durchgeführt wird. Das Entwicklungsteam verfügt typischerweise über das fachliche Know-how, um sich selbst zu verbessern. Die Entscheidung, wann und wie die Verfeinerung erfolgt, liegt jedoch bei dem Scrum-Team.Product-Backlog-Verfeinerung beträgt normalerweise nicht mehr als 10 % der Entwicklungszeit des Teams.

Meeting zur Verbesserung des Produkt-Backlogs

Das Entwicklungsteam ist für die gesamte Schätzarbeit verantwortlich. Der Product Owner kann die Entscheidungen des Teams beeinflussen, indem er ihnen bei der Abwägung von Kompromissen hilft. Die endgültige Schätzung wird jedoch von den Personen getroffen, die die Arbeit ausführen.

Überwachung des Fortschritts über Sprint-Ziele

Zu jedem Zeitpunkt kann der verbleibende Aufwand, um das Sprint-Ziel vom insgesamt erledigten Arbeitssumme abgezogen werden. Der Product Owner muss den Gesamtaufwand, der noch zu erledigen ist, mindestens nach jedem Sprint-Review. Der Product Owner vergleicht diesen Betrag mit dem verbleibenden Aufwand aus früheren Sprint-Reviews, um den Fortschritt gegenüber dem erwarteten Arbeitseinsatz zum benötigten Zeitpunkt zu bewerten. Diese Information ist für alle Stakeholder transparent.

Scrum berücksichtigt die Zeit, die für die Items im Produkt-Backlog aufgewendet wird, nicht. Wir kümmern uns nur um die verbleibende Arbeit und die Datumsvariable.

Verschiedene Diagramme oder Burn-down-Diagramme und andere Planungspraktiken können verwendet werden, um den Fortschritt vorherzusagen. Sie haben sich als nützlich erwiesen. Dies ersetzt jedoch nicht die Bedeutung des empirischen Denkens. In komplexen Umgebungen ist ungewiss, was geschehen wird – nur das, was bereits geschehen ist, kann zur Ableitung zukunftsgerichteter Entscheidungen genutzt werden.

Scrum-Sprint-Fortschritt