Was ist eigentlich ein Product Backlog?

Was ist eigentlich ein Product Backlog? Definitiv ist das Product Backlog mehr als nur die Antwort auf die Frage, wohin denn eigentlich mit den User Stories. Im Kern eine priorisierte Liste von Anforderungen stellt es gewissermaßen das wichtigste Werkzeug fürs Produktmanagement und damit den Product Owner dar.

Bei der Produktentwicklung mit Scrum ist das Product Backlog eine geordnete Liste von Anforderungen an das Produkt. So gesehen stellt es das wichtigste Werkzeug für das Produktmanagement durch den Product Owner dar.

Seine Aufgabe ist es, die Anforderungen im Product Backlog zu pflegen, in eine sinnvolle Reihenfolge zu bringen und nach und nach um die nötigen Details (gerne auch in Zusammenarbeit mit dem Team) zu ergänzen, damit das Entwicklerteam sie schätzen und schließlich in einen Sprint aufnehmen kann. Typischerweise beinhaltet das Product Backlog deshalb auch irgendwann Schätzungen zu den einzelnen Items, wobei in Scrum in der Regel nicht in Zeiteinheiten sondern relativer Komplexität geschätzt wird.

Im einfachsten und vielleicht gar nicht mal unpraktischsten Fall ist das Product Backlog einfach ein Spreadsheet (etwa in Excel gepflegt), solange das den Anforderungen des Product Owners gerecht wird.

Was kommt ins Product Backlog und was nicht?

Ein weit verbreitetes Missverständnis ist, dass im Backlog User Storys landen. Das kann natürlich eine Möglichkeit sein, um Anforderungen zu beschreiben, aber tatsächlich handelt es sich nur um Einträge, die je nach Priorisierung irgendwann abgearbeitet werden sollen. Das können sein:

• Benutzeranforderungen

• Nicht-funktionale Produktanforderungen (etwa Compliance-/Security-Anforderungen)

• Arbeiten, die der Verbesserung der Produktqualität dienen (z.B Refactoring-Arbeiten)

• Notwendige Bugfixes

• Impediments

Für Letztere wird hin- und wieder auch ein eigenes Backlog vorgeschlagen, aber da das Product Backlog letztlich die Quelle ist, aus der bei der Sprint-Planung geschöpft wird, kann eine einzelne Quelle für alle Arbeiten die Planung erleichtern.

Die Einträge im Product Backlog müssen nicht auf einzelne Aufgaben runter gebrochen sein – im Gegenteil: die Zerlegung in einzelne Aufgaben erfolgt durch das Team im Rahmen der Sprint-Planung.

Was zeichnet ein gutes Product Backlog aus?

Das oberste Ziel eines Product Backlogs ist es, den maximalen (Geschäfts-)wert aus dem Produkt herauszuholen und Risiken früh auszuräumen. Folglich muss sich ein Product Backlog daran messen.

Dafür gilt der Leitsatz: Ein gutes Product Backlog ist DEEP. Dahinter verbergen sich die folgenden Punkte:

• Detailed appropriately: Die Items sind angemessen detailliert, also was zuerst bearbeitet werden soll ist so detailliert wie es für diesen Zweck erforderlich ist. Alle anderen Einträge können (und sollten tatsächlich) nicht übermäßig detailliert sein. Schließlich könnte sich rausstellen: diese Anforderung brauchen wir nicht mehr und fliegt deshalb raus.

• Estimated appropriately: Wenn ein Item in den nächsten Sprint aufgenommen werden soll, sollte es mit einer Schätzung (z.B mit Story-Points) versehen sein. Diese hilft dem Product Owner bei der Priorisierung und natürlich um festzustellen, ob ein Item im nächsten Sprint abschließend bearbeitet werden kann oder weiter aufgebrochen werden muss.

• Emergent: Das Product Backlog ist zu keiner Zeit fertig, sondern entwickelt sich im Verlauf der Entwicklung. Das heißt, dass zu jeder Zeit Anforderungen rausfliegen, dazukommen, in kleinere Einheiten geteilt und mit Details versehen werden (können). Dabei sollte sich der Product Owner natürlich am Feedback aller Stakeholder, den Marktgegebenheiten und ähnlichen Faktoren orientieren. Responding to change eben.

• Prioritized: Eigentlich braucht man das fast nicht erwähnen, aber das Backlog muss natürlich eine Priorisierung abbilden, um das oben genannte Ziel zu erreichen. Am einfachsten ist das sicherlich mit einer sortierten Liste zu erreichen, mit den höcht-priorisierten Items on-top.

Für Einträge, die im nächsten oder einem der nächsten Sprints bearbeitet werden soll, gibt es weitere Leitsätze, an denen man sich orientieren kann. Darauf gehe ich in einem zukünftigen Artikel ein. Für die Ungeduldigen enthält beispielsweise dieser englischsprachige Artikel eine Menge Infos.