Das Product Backlog ist ein dynamisches, lebendiges Artefakt für Scrum Teams. Vielen Scrum Teams gelingt es, das Sprint Backlog „sauber“ zu halten und zu verhindern, dass von außen neue (und natürlich extrem wichtige) Aufgaben an das Team herangetragen werden. Vielen Product Ownern fällt die Priorisierung des Product Backlogs sehr viel schwerer.

Die Idee, die hinter dem Product Backlog steht, ist im Grunde ziemlich simpel. Wir haben eine alleinige Quelle für Anforderungen an das Team, um so zu vermeiden, dass von anderen „dringende Aufgaben“ an unser Entwickler-Team herangetragen werden. Die Anforderungen unserer Stakeholder fließen nun nicht mehr direkt dorthin. Stattdessen wandern sie zunächst in das Product Backlog, wo sie dann von einem alleinigen Verantwortlichen (nämlich dem Product Owner) nach Geschäftswert priorisiert werden. Das Gezerre, das durch unterschiedliche Interessen und Vorstellungen verschiedener Stakeholder entsteht, wird in Scrum also verlagert. Aus der täglichen Arbeit heraus, hinein das Product Backlog.

Der Product Owner kümmert sich mit dem Entwickler-Team darum, dass die oben stehenden Anforderungen im Product Backlog durch ein gemeinsames Refinement möglichst klar und transparent sind. Anforderungen, die weniger wichtig sind, stehen weiter unten und sind auch weniger ausgearbeitet. Für die Arbeit in Sprints ist diese Sortierung des Product Backlogs extrem wichtig. Es stellt sicher, dass im Sprint selbst nur solche User Stories abgearbeitet werden, die so klar wie möglich sind.

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. (Scrum Guide, Seite 15)

Das Phänomen

In der Praxis verschiebt sich das Gezerre um Aufgaben und Priorisierung jedoch lediglich, ohne aufgelöst zu werden. Der Product Owner sortiert sein Product Backlog gemeinsam mit den Entwicklern und arbeitet die oben stehenden Tasks aus, sodass die Entwickler ein gutes Gefühl haben, diese Aufgaben im nächsten (und vielleicht sogar übernächsten) Sprint abarbeiten zu können. Bis jetzt sieht alles prima aus.

Doch in der nächsten Sprint Review stellen einige Stakeholder für sie wichtige Anforderungen und Aufgaben an den Product Owner. Diese Aufgaben befanden sich zuvor weiter unten im Backlog. Sie sind deshalb noch nicht ausgearbeitet worden und folglich sehr unklar. Wenn der Product Owner in solchen Situationen aufgrund des Druckes von außen nachgibt und diese User Stories so weit nach oben verschiebt, dass sie auch im folgenden Sprint landen werden, hat niemand etwas gewonnen: Das Sprint Backlog wird zwangsläufig mit unklaren Anforderungen gefüllt. Das Potenzial für böse Überraschungen während des Sprints steigt dramatisch an und die Wahrscheinlichkeit, das Sprinziel nicht zu erreichen, ebenfalls. Gleichzeitig wandern klare und transparente Anforderungen im Product Backlog weiter nach unten. Sie fallen in den Sleep-Modus und es kann sehr gut sein, dass sich ihre Bedingungen bereits wieder verändert haben, wenn sie dann doch irgendwann wieder hervorgeholt werden. Mit dem Ergebnis, dass wir für diese User Stories ein erneutes Refinement benötigen.

Was sind die Gründe?

Die Wurzel dieses Problems ist – meiner Meinung nach – ein nicht respektierter Product Owner und ein falsches Verständnis von Agilität seitens der Stakeholder. Für Letztere scheint die Sprint Review oft ein Ort, an dem sie spontan und ohne jegliche Vorwarnung wichtige Anforderungen in den Sprint hineindrücken können, weil sie dringend etwas erledigt haben wollen. Und das unabhängig davon, wie klar diese Anforderungen aktuell sind. Trifft diese Vorstellung von „Agilität“ auf einen schwachen, wenig respektierten Product Owner nimmt das Unheil seinen Lauf. Aufgrund des Druckes von außen sieht er sich nicht in der Lage sieht, diese Anforderungen weiter unten in sein Product Backlog zu stellen. Das Backlog wird geflippt: Klare und kleine User Stories stehen weit unten und unklare, große User Stories an der Spitze.

Was sagt der Scrum Guide dazu?

Im Scrum Guide finden wir dazu zwei wichtige Punkte:

The Product Owner is one person, not a committee. […] For the Product Owner to succeed, the entire organization must respect his or her decisions. (Scrum Guide, Seite 6)

Scrum möchte also erreichen, dass es eine einzige Person gibt, die über die Priorisierung des Product Backlogs entscheidet. Und alle Beteiligten haben seine Entscheidungen über die Priorisierung zu respektieren. Solange das nicht der Fall ist, werden immer wieder unklare und wenig spezifische Anforderungen in den Sprint des Entwickler-Teams gelangen und es dadurch langsamer machen.

Der Scrum Master eines Teams ist in solchen Situationen ebenfalls stark gefordert. Er muss allen Beteiligten klar machen, welche Auswirkung dieses Verhalten hat und dass es wichtig ist, die Rolle des Product Owners zu respektieren.

Helping employees and stakeholders understand and enact Scrum and empirical product development; (Scrum Guide, Seite 8)

Diese Situation kann meiner Erfahrung nach häufig ziemlich ungemütlich werden. Denn es bedeutet, Stakeholdern klar zu machen, dass sie selbst die größte Ursache dafür sind, dass die Performance des Scrum Teams leidet. Der ausgeübte Druck bewirkt, dass sich unklare Anforderungen am Product Owner vorbeischlängeln, sich ihren Platz weit oben im Product Backlog suchen und so ihren Weg in das Sprint Backlog finden.

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos