Product Backlog

Das Product Backlog Management ist die zentrale Aufgabe des Product Owners. Das Product Backlog stellt dabei eine umfassende Liste mit Backlog Items dar. Diese Einträge beinhalten die Anforderungen und Funktionen, mit denen das Produkt entwickelt werden soll. Die Backlog Liste ist nie fertig und wird immer weiter entwickelt.

Das Product Backlog bildet alle Anforderungen der Product Roadmap ab, beschreibt sie allerdings im Unterschied zur Roadmap sehr detailliert, enthält aber keine zeitlichen Angaben dazu, wann bzw. für welches Release das Item umgesetzt werden soll. Beide sollten konsistent gepflegt werden, um Unstimmigkeiten zu verhindern.

Generell soll das Product Backlog DEEP sein, also nach dem DEEP Prinzip gefüllt sein.

Dabei steht das D für Detailed Appropriately, also angemessen oder passend detailliert. Items mit einer höheren Priorität sollen ausführlicher als Items mit niedrigerer Priorität beschrieben werden. Dabei sollen die höher priorisierten Einträge gerade so ausführlich beschrieben sein, dass man sie gut umsetzen kann.

Das erste E steht für Estimated, also geschätzt. Das bedeutet, dass der Aufwand für die Umsetzung der Product Backlog Einträge geschätzt ist, somit die Items mit zum Bespiel Story Points versehen sind. Zum Thema Schätzen und den Story Points werden wir später noch kommen, wenn wir uns mit dem Refinement befassen.

Das zweite E steht für Emergent, also entwickelnd bzw. änderbar. Das bedeutet, dass das Backlog nie still steht. Es wird fortlaufend geändert und aktualisiert. Dabei werden neue Items hinzugefügt, andere erweitert und verfeinert und manche auch wieder entfernt.

Dann hätten wir da noch das P, das für Prioritized, priorisiert, steht. Soll heißen, alle Einträge im Product Backlog sind der Priorität nach in einer geordneten Reihenfolge, wobei diejenigen mit der höchsten Priorität ganz oben stehen.

Für die Einhaltung des DEEP-Prinzips ist der Product Owner zuständig. Er entscheidet über die Aufnahme neuer und das Ändern bestehender Einträge und auch darüber, ob ein bestimmtes Item aus dem Backlog entfernt wird. Er bringt alle Einträge in die richtige Reihenfolge, denn er ist derjenige, der die Prioritäten kennt und festlegt. Diese werden in fortlaufenden Gesprächen mit den Stakeholdern immer wieder abgeglichen und definiert.

Dabei fließen Faktoren hinsichtlich Kosten, Risiko und Nutzen ein, aus deren Zusammenspiel der Geschäftswert bestimmt wird. Dieser ist maßgeblich für die Priorisierung des Backlogs. Ein gut gepflegtes und priorisiertes Product Backlog erleichtert ein ganzes Stück weit die Durchführung des Refinements und des Sprint Plannings und lässt es effektiver von statten gehen.

Vorgehen des Product Owners

Stellen wir uns vor, dass viele unterschiedliche Anforderungen an den Product Owner herangetragen werden. Zum einen von verschiedenen Stakeholdern, zum anderen aus anderen Abteilungen des Unternehmens. Wie geht man nun damit um? Alle Ideen und Wünsche müssen zu erst analysiert werden. Dafür gibt es verschiedene Möglichkeiten.

Zum einen können die neuen Anforderungen eines Stakeholders bei anderen Skateholdern abgeklärt und so der allgemeine Nutzen in Erfahrung gebracht werden. Natürlich kann man auch alle Stakeholder zusammen an einen Tisch holen. Ein sofortiges Feedback aller erspart damit viel Zeit.

Man kann auch einen Prototypen mittels Design Thinking erstellen und diesen dann direkt auf Relevanz und Nutzen testen lassen.

Gewiss hilft die eigene Erfahrung auch weiter und anhand dieser können einige Ideen eingeschätzt und eingeordnet werden.

Basierend auf dem Ergebnis der Analysen entscheider der Product Owner dann, ob die Anforderung mit in das Product Backlog eingefügt wird oder nicht.

Wie erstellt man am besten das Product Backlog?

Wir haben in den letzten Beiträgen schon viel über den Weg der Produktdefinition und Planung gehört. Von der Produkt Vision über die Produkt Strategie bis hin zur Produkt Roadmap konnten wir genügend Informationen für das Produkt Backlog sammeln. Aus diesen ganzen Produktwünschen, Anforderungen und Merkmalen können wir nun die Backlog Einträge ableiten und erstellen. Dies geschieht durch die Formulierung von angemessen großen User Stories, dem Erstellen der Definition of Done sowie dem Schreiben von Akzeptanzkriterien.

Bevor wir zu diesem Thema kommen, werden wir uns aber noch einmal mit möglichen Problemen bei der Backlog Verwaltung befassen.

Immer ein unschönes Problem wird es, wenn das Backlog zu voll und unübersichtlich wird. Das kann daran liegen, dass der Product Owner keine Anforderungen aussortiert. Das geschieht häufig, wenn er nicht “nein” sagen kann. Ansammlungen von User Stories aus einigen Jahren können die Folge sein. Als Product Owner sollte man sich wirklich überlegen, ob man nicht auch mal einen Wunsch zurückweist, wenn nach der Analyse herausgekommt, dass dieser keinen großen Nutzen für andere hat oder wirtschaftlich nicht tragbar ist. In Gesprächen mit Stakeholdern und dem Veranschaulichen der höher priorisierten Anforderungen zum Produkt dürfte dies kein allzu großes Problem sein. Auch hier kann ein Meeting mit allen Stakeholdern eventuell unterstützen. Im direkten Austausch ordnet man seine Anforderungen dann eventuell schon von selbst neu.

Eine weitere Abhilfe kann ein Ablaufdatum zu Userstories sein. das heißt, dass Backlogeinträge ein Datum in der Zukunft erhalten, bis zu dem sie weiter bearbeitet werden müssen. je nachdem, wie umfangreich das Projekt ist und auf wie lange es in etwa ausgelegt ist, kann diese Zeitspanne zwischen einem halben und zwei Jahren betragen. Wenn der Eintrag sozusagen abgelaufen ist, wird er aus dem Product Backlog gelöscht. Diese Variante sollte aber wirklich nur als Fallback Lösung betrachtet werden. Wichtiger ist es, dass versucht wird das Product Backlog dahingehend von Anfang an an richtig zu pflegen.

Das nächste Problem sind unklare Formulierungen der User Stories. Wenn der Product Owner selbst irgendwann nicht mehr weiß, was eigentlich mit dem Item gemeint war, muss er an seinem Formulierungs-Know How arbeiten.

Wenn das Product Backlog nicht auf die Product Roadmap abgestimmt ist, kann dies schwerwiegende Folgen bei der Umsetzung, der Releaseplanung und -erstellung haben. Wenn Abhängigkeiten nämlich nicht beachtet, oder Umpriorisierungen nicht konsistent gehalten werden, dann kann dies zu anschließendem Mehraufwand führen, da entstehende Fehler im Programmcode wieder behoben werden müssen. Umgehen kann man das Problem, indem man kontinuierlich darauf achtet, dass Roadmap und Backlog im Einklang miteinander sind und beides auf aktuellem Stand gehalten wird.

Fassen wir zusammen, dass ein gut gepflegtes und ordentlich priorisiertes Product Backlog essentiell für einen erfolgreichen Projektverlauf und der Grundstein für qualitativ hochwertige Umsetzungen ist.