Was ist ein Product Backlog?
Ein Product Backlog enthält alle Arbeit, die zur Erstellung eines erfolgreichen Produkts notwendig ist.
Product Backlog-Pflege
Sammeln von Anforderungen - Aufbau des Product Backlogs
Ausgehend von der Produktvision werden die Funktionen erfasst und gesammelt, die das Produkt bieten soll, um die Bedürfnisse der einzelnen Benutzerrollen abzudecken.
Jede geplante Funktion wird dabei in Form einer User-Story erfasst, die Gesamtheit aller User-Stories und anderer Arbeiten, die für die Erstellung des Produkts erforderlich sind, bildet das Product Backlog. Dabei wird das initial aufgebaute Product Backlog mit Sicherheit auch User-Stories umfassen, die im Projektverlauf durch neue Erkenntnisse als irrelevant erkannt und deswegen verworfen werden. In weiteren Anforderungsmeetings oder Backlog Groomings werden im Laufe des Projekts wiederum User-Stories hinzukommen, die zu Beginn nicht beachtet wurden.
Man sollte also nicht verbissen versuchen, jede denkbare Funktion für jede Benutzerrolle in den initialen Product Backlog zu pressen, sondern sich vielmehr darauf konzentrieren, diejenigen User-Stories zu finden, die die Erfüllung der Produktvision sicherstellen, wenn eine erste Version des geplanten Produkts ausgeliefert wird. In der Regel ist hier ein klassisches Brainstorming die zielführende Methode.
Grundsätzlich liegt die Anforderung an eine sinnvolle User-Story in der Erfassung der folgenden drei Punkte:
- Für welche Benutzerrolle ist die Funktion?
- Welche Wirkung hat die Funktion im System?
- Welchen Mehrwert bietet die Funktion für den Nutzer?
Eine beispielhafte User Story für ein Job-Portal könnte somit lauten: Als Jobsuchender (1) möchte ich Stellenanzeigen nach Stichwörten durchsuchen können (2), um für mich interessante Stellenanzeigen zu finden (3).
Vor der konkreten Umsetzung müssen selbstverständlich weitere weitere wesentliche Bestandteile von User-Stories, wie z.B. Akzeptanzkriterien, ergänzt werden.
Priorisierung des Product Backlog
Für den Projektverlauf ist es essenziell, die wichtigsten bzw. wertvollsten User-Stories zuerst umzusetzen. Daher ist eine Priorisierung erforderlich.
Die Frage hierbei ist: Wie ist der Wert einer User-Story zu bestimmen? Einen tatsächlichen monetären Wert zuzuweisen, ist wenig zielführend, da zu Projektbeginn zu viele Unbekannte im Spiel sind. Deswegen vereinfacht man das Problem und behilft sich mit Priorisierungskategorien. Eine sinnvolle Kategorisierungsmöglichkeit bietet das Vorgehen nach dem MoSCoW-Prinzip (Must, Should, Could, Won’t).
Grundsätzlich stehen sich der angenommene Nutzwert, den eine Funktion dem User bietet, und die geschätzten Kosten gegenüber. Der Gesamtwert einer User-Story ergibt sich aus dem Verhältnis dieser beiden Größen. Unserer Erfahrung nach ist es jedoch sinnvoll, im ersten Anforderungs-Workshop zunächst nur Aussagen zum Nutzwert zu treffen und nachgelagert den Aufwand zu beschätzen sowie eine Re-Priorisierung vorzunehmen.
Product Backlog Board
Wenn in Projekten längerfristig gearbeitet wird – beispielsweise an komplexen Software-Produkten -, empfiehlt sich die Etablierung eines Product-Backlog-Boards.
Das Product-Backlog-Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, sodass sich alle Teammitglieder und auch die Stakeholder jederzeit darüber informieren können.
Der Aufbau eines Product Backlog Boards schaut in etwa wie folgt aus:
Der Product Owner bereitet gemeinsam mit dem Team die Elemente des Product Backlogs soweit vor, dass sie bereit für eine Umsetzung sind. Die für eine Umsetzung bereiten Elemente werden in einem gesonderten Bereich für die "ready items" vorgehalten.
Zugleich ist dem Team auch jederzeit ersichtlich, welche Elemente des Product Backlogs als nächstes soweit vorangetrieben werden sollen, dass sie in die Umsetzung gehen können.
Interessante Links
- Roman Pichlers Top Ten Product Backlog Tips
- Die nächsten Schritte vor Augen dank Product-Backlog-Board
- Das Product Backlog Board
- Roman Pichler: The Product Backlog Board