Das Product Backlog in Scrum – Priorisierung als Erfolgsfaktor

Das Product Backlog ist das Bindeglied zwischen dem Product Owner und dem Team in Scrum. Darin legt dieser eine nach Kriterien wie wirtschaftlicher Nutzen, Aufwand, Risiko und Notwendigkeit priorisierte Liste von Anforderungen/Requirements an das zu entwickelnde Produkt an. Die Grundlage hierfür bilden die User Stories und Epics. Diese aus Anwendersicht generierte „To-do-Liste“ ist das Ergebnis des Release Planning, spiegelt die Produkt-Vision wider und wird im Projektverlauf immer weiter verfeinert.

Das Product Backlog in Scrum ist also kein endgültiger, zu Projektstart für alle Zeiten festgelegter Plan wie im klassischen Projektmanagement, sondern es kann jederzeit um neue Anforderungen erweitert werden. Indem es dynamisch und offen für Veränderungen ist, erfüllt es eine der wesentlichen Charakteristika agilen Projektmanagements.

Von der Anforderung zum Task für das Team

Insgesamt enthält das Product Backlog Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen. Im Sprint Planning legt sich das Scrum-Entwicklungsteam auf die Umsetzung jeweils einer Anforderung im nächsten Sprint fest und leitet hierzu aus einem der Einträge konkrete Tasks ab. Wurde dann eine der Anforderungen erfolgreich vom Team realisiert (oder vom Product Owner wieder verworfen), so wird diese aus dem Product Backlog entfernt.

Zudem werden auf Basis neuer Erkenntnisse regelmäßig die Schätzwerte für die Requirements spezifiziert und aktualisiert sowie die Prioritäten bedarfsgerecht neu gesetzt. Hierfür ist zwar alleine der Product Owner zuständig, allerdings berücksichtig er im Rahmen der Backlog Reviews idealerweise immer den Input und das Feedback der Stakeholder und Entwickler nach der vorangegangenen Iteration. Wichtig ist, dass die Veränderungen im Product Backlog nicht während der Sprints stattfinden bzw. keinen (negativen) Einfluss auf den laufenden Sprint haben.

Methoden zur Priorisierung im Product Backlog

Je besser das Product Backlog organisiert und priorisiert ist, desto optimaler kann der Workflow in Scrum vonstattengehen. Insofern ist es (mit)entscheidend für den Erfolg eines agilen Projektes. Die Priorisierung kann dabei auf verschiedene bewährte Methoden zurückgreifen:

• Kano-Analyse: Durch die Befragung von Anwendern können Funktionalitäten in verschiedene Kategorien eingestuft werden.
• MoSCoW-Schema: Hierbei werden die Einträge in Must-haves, Should-haves, Could-haves und Won’t-haves unterteilt und priorisiert.
• Theme Screening: Diese Methode dient dazu, User Stories, Themes (Gruppen von User Stories) und Epics gegeneinander abzuwägen und Plus- oder Minuspunkte zu vergeben.
• Theme Scoring: Grundsätzlich mit dem Theme Screening vergleichbar – allerdings ist die Bewertung hier differenzierter und genauer.
• Relative Weight: Bei der relativen Gewichtung werden für die Einträge individuelle Werte zwischen 0 (niedrig) und 9 (hoch) hinsichtlich Vorteil, Strafe, Risiko und Kosten vergeben.