Das fragmentierte Product Backlog konsolidieren

Unser gemeinsamer strategischer Ausblick zum Produkt-Ziel

Ein gutes Product Backlog ist unser gemeinsamer strategischer Ausblick zum Produkt-Ziel. Es gibt den Entwicklern eine Orientierung zur Ausgestaltung der Arbeit im Sprint. Es ermöglicht ihnen, sich proaktiv und effizient mit ihrer Expertise auch bei frühen und groben Backlog Items und der Ausrichtung des Product Backlogs einzubringen. So schaffen wir es, dass naive Fehlentscheidungen von der Fachseite her stehen bleiben und in der Entwicklung später zu bösen Überraschungen führen können.

Das Produkt Backlog ermöglicht es dem Scrum Team und insbesondere dem Product Owner die Stakeholder effektiv in die gemeinsame Ausgestaltung des Produktes zu integrieren. Anstelle sich von widersprüchlichen Anforderungen und Erwartungen, resultierend aus sich wiedersprechenden Anforderungen unterschiedlicher Stakeholder treiben zu lassen, wird das Scrum Team durch dieses gute Product Backlog zum proaktiven Lösungsanbieter.

 

Die richtigen Optionen zur Gestaltung sinnvoller Sprints

Gleichzeitig zeichnet sich ein gutes Product Backlog durch die Vorbereitung der richtigen Optionen aus, aus denen das Scrum Team in Kombination mit dem Ausblick sinnvolle Sprint-Ziele angehen kann.

Leichtgewichtige Items ausreichend vorbereiten
Aus der Prägung alter Arbeitsweisen erwarten hier viele Menschen, dass diese Option möglichst klar im Geiste guter Spezifikationen ausgestaltet sind. Dies ist jedoch ein weiterverbreiteter Irrglaube. Die Idee ist vielmehr, dass sie gut genug vorbereitet sind für ein eingespieltes Scrum Team.

• Die Entwickler haben nicht einfach nur alle Fähigkeiten zur Umsetzung, sondern um von leichtgewichtigen Anforderungen zu einsetzbaren Lösungen zu kommen.
• In dieser Aufstellung werden wichtige Fragestellungen im Vertrauensverhältnis zwischen PO und Entwicklern im Sprint geklärt und ermöglichen ein ganz anderes Level an Agilität.
• In diesem leichtgewichtigen Vorgehen, lernen wir aus jedem Sprint dazu, um schon das Richtige vorzubereiten aber eben auch nicht mehr.

Wer hier aus Gewohnheit mit technischen Anforderungen und  einem User-Story-Template als Deckblatt arbeitet, hat nicht verstanden, wie wir mit Scrum effektiv bessere Ergebnisse liefern.

 

Ein Backlog besteht aus nutzerzentrierten Sub-Zielen und nicht aus fragmentierten Tasks & Arbeitspaketen!

Jedes Backlog-Item für sich sollte einen echten Mehrwert für das Produkt stiften. Also dem  Nutzer ein Lächeln auf das Gesicht zaubern oder zumindest uns ein Ergebnis liefern, mit dem wir mit ihm in den Dialog gehen können.
Nicht auf den Nutzer ausgerichtete Items sollten in einer nutzerzentrierten Entwicklung die Ausnahme sein. Auch für diese Items gilt, dass hier klar herausgestellt ist, welchen Mehrwert sie uns liefern.

Um diese Art von Items zu erreichen, hat es sich für mich bewährt, oft die bestehenden fragmentierten Items zu größeren Items zusammenzuführen. Um bei denen wir wieder in der Lage zu sein, den Wert zu nennen. Wenn diese dann zu groß für den Sprint sind. sollten wir diese im Geiste inkrementeller Entwicklung runter brechen. Das heißt, die Vereinfachungen früher in  einsetzbare minimale Lösungen splitten, um schon früher den Nutzern einen Wert geben oder davon zu lernen.

 

Wo profitieren wir von einem guten Product Backlog?

In dem vorherigen Abschnitt habe ich ja bereits durchblicken lassen, dass ein solches Produkt Backlog uns dabei hilft, gemeinsam in einem anspruchsvollen Umfeld gute Lösungen zu entwickeln. Wenn du dazu mehr erfahren möchtest, höre mal in die Folge „Lernen aus Inkrementen“ rein.
Zusätzlich ist ein gutes Product Backlog für mich der Schlüssel zur Aufstellung eines guten Scrum Teams:

• Aus dem gemeinsamen Ziel lässt sich die enge Zusammenarbeit im Scrum Team motivieren.
• Aus der Ableitung welche Skills wir für typische Backlog-Items benötigen, können wir die Aufstellung des Scrum Team ableiten oder reflektieren.
• Mit dem ersten groben Product Backlog kann ein Product Owner in den Austausch mit dem Scrum Team gehen, um gemeinsam die Aufstellung zur Arbeit mit leichtgewichtigen Anforderungen auszugestalten.

Gerade die Ausrichtung der eigenen Arbeit, hilft dabei die eigene Umgebung konkret und pragmatisch auszugestalten.

 

Nicht immer ist es angebracht, dass Product Backlog top-down vom Ziel zu entwickeln

Im Start einer neuen Scrum Umgebung oder in meinem Product Owner Training nutzen wir ein Vorgehen, wo wir vom übergreifenden Produkt-Ziel eine gute Aufstellung mit dem Product Backlog erarbeiten.
In Umgebungen, in denen bereits ein gewachsenes Product Backlog existiert, ist dies in der Regel nicht möglich. Da diese unübersichtliche Ansammlung an Anforderungen an unterschiedlichste Versprechungen und Erwartungen gebunden ist.
Eigentlich müssten wir hier:

• Die Arbeitspakete und Tasks zu Items bündeln, die für sich Wert stiften
• Eine konsistente übergreifende Ausrichtung auf das Produkt-Ziel schaffen
• Die wertstiftenden Items so unterbrechen, dass wir früh einsetzbare Lösungen liefern und aus diesen Inkrementen offensiv Unbekannte validieren können.

Leider sehen sich aus der verfahrenen Ausgangslage mit den unterschiedlichste Versprechungen und Erwartungen viele Product Owner nicht in der Lage das Produkt alleine zu konsolidieren. Aus diesem Grund bietet es sich hier an die Stakeholder und Entwickler in einem gemeinsamen Workshop zusammenzubringen.

 

Backlog on the Floor – Ein Workshop-Ansatz, um gemeinsam von einer Ansammlung an Tasks zu einem guten Product Backlog zu kommen

In dem in der Podcast-Folge beschriebenen Vorgehen, breiten wir zuerst das Product Backlog aus und arbeiten suggestive diese lose Sammlung an Tasks auf.
Hier die Beschreibung des Formates in Englisch:

Backlog on the Floor – Description (English) [PDF]

Bitte meldet euch, falls ihr euch eine deutsche Beschreibung wünscht. Ich werde diese dann in den kommenden Wochen nachliefern, falls es genügend Bedarf geben sollte.

 

Alternativ kann ein mutiger PO die Aufarbeitung eines Backlogs auch alleine anstoßen

Der Knackpunkt ist, sich aus der lähmenden Blockade durch die sich wiedersprechenden Anforderungen zu lösen und eine übergreifende Klärung mit allen Stakeholder zu erlangen. Dies erreichen wir, in dem gemeinsamen Workshop Format, indem der Facilitator im Zweifel durch eine willkürliche Sortierung des Backlog die Klärung der Prioritäten anstößt.

Dies kannst du als Product Owner natürlich auch durch das alleinige Aufräumen des Backlogs erreichen. Aufbauend würde ich dann die Stakeholder über das neue konsolidierte Backlog, wie folgt, informieren:

„Damit wir gemeinsam und fokussiert in Richtung des übergreifenden Produkt-Ziels arbeiten können, habe ich das Product Backlog konsolidiert. Ich habe versucht den unterschiedlichen Interessen bestmöglich Rechnung zu tragen. Das Product Backlog ist übergreifend nach den Prio-Kriterien A, B, C periodisiert. Wir planen ab dem kommenden Donnertag den nächsten Sprint auf Basis dieses konsolidierten Backlogs zu planen. Falls euch die Priorisierung oder die konkrete Sortierung des Backlogs nicht gefällt, bitte ich euch davon Abstand zunehmen und mit mir bilateral zu versuchen das Backlog umzusortieren. Dafür gibt es aktuell zu viele unterschiedliche Interessen. Deswegen würde ich euch gerne in diesem Fall als Sponsor und Unterstützer für die Durchführung eines gemeinsamen Workshops gewinnen. In diesem Workshop können wir dann übergreifend Prio-Kriterien konkret umpriorisieren.
Aber natürlich werden wir das Backlog suggestive aus den Erkenntnissen eines jeden Sprints weiter gemeinsam nachjustieren. Ich freu mich auf die gemeinsame weitere Ausgestaltung des Produktes mit euch, euer PO.“

Ich hoffe diese Folge hat euch einige konkrete weitere Anstöße zur Optimierung eures Product Backlogs gegeben. Bitte gebt gerne auch Feedback, falls ihr euch weitere Folgen zur Pflege und Ausgestaltung des Backlogs wünscht. Dann würde ich diese gerne genau an eure Bedürfnisse ausrichten und anpassen.

Schreibt uns einfach 😉