Stefan Wolpers Juli 30, 2019

Liberating Structures für Scrum (3): Das Product Backlog

In Kürze: Das Liberating Structures Product Backlog Meetup

Das vierte Liberating Structures für Scrum-Meetup befasste sich mit dem Product Backlog, genauer gesagt mit jenen Product Backlog-Problemen, die später dazu führten, dass Sprint Plannings fehlschlagen und Scrum Teams unter ihren Möglichkeiten bleiben; wie das Sprichwort besagt: garbage in, garbage out.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 33.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Liberating Structures für Scrum

Liberating Structures, entwickelt von Keith McCandless und Henri Lipmanowicz, umfassen eine Reihe von einfach zu erlernenden, dennoch sehr produktiven Übungen zur Verbesserung der Zusammenarbeit in — nach Scrum-Standards auch (sehr) großen — Teams. Liberating Structures überwinden dabei traditionelle Kommunikationsansätze wie Präsentationen, vorstrukturierte Diskussionen oder ein weiteres unorganisiertes Brainstorming, bei dem die lautesten Teilnehmer die Oberhand gewinnen.

Liberating Structures eignen sich gut, um das Engagement der Teilnehmer von Scrum-Events zu verbessern und so die Art von Ergebnissen zu stimulieren, die für die Schaffung von lernenden Organisationen notwendig sind. Liberating Structures bieten auch ausgezeichnete Werkzeuge, um das Product Backlog Refinement oder die Definition von Done einer IT-Organisation zu verbessern.

Schließlich sind Liberating Structures ein großartiges Instrument, wenn größere Gruppen zu Retrospektiven, zur Selbstselektion von Teams oder zur Ermittlung der nächsten Schritte zur Umsetzung einer Produktstrategie zusammenkommen.

Das Product Backlog

Das Product Backlog ist eines der drei Scrum-Artefakte und spiegelt jederzeit die bestmögliche Nutzung der Zeit des Entwicklungsteams wider. Gemäß dem Scrum Guide:

• Ist das Product Backlog ein geordnetes Verzeichnis von allem, was bekanntermaßen im Produkt benötigt wird.
• Ist es die einzige Quelle für Anforderungen an das Produkt.
• Listet das Product Backlog alle Features, Funktionen, Anforderungen, Erweiterungen und Korrekturen für zukünftige Releases auf.
• Ist das Product Backlog niemals komplett.
• Ist das Product Backlog dynamisch; es ändert sich ständig, um zu reflektieren, was das Produkt braucht, um angemessen, wettbewerbsfähig und nützlich zu sein.
• Das Refinement des Product Backlogs ist der Vorgang, bei dem Details, Schätzungen und Positionen zu Einträgen im Product Backlog hinzugefügt werden.
• Dies ist ein fortlaufender Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam an den Details der Product Backlog-Einträge arbeiten.
• Der Product Owner ist für das Product Backlog verantwortlich, einschließlich dessen Inhalt, Verfügbarkeit und Positionierung von Einträgen.

Quelle: Scrum Guide.

Das Fazit des letzten Meetups zu Liberating Structures für das Sprint Planning war offensichtlich: Erfolgreiche Sprint Plannings hängen von einem gut vorbereiteten, umsetzungsfähigen Product Backlog ab, bei dem das Scrum-Team die schwere Arbeit bereits während des Product Backlog-Refinements bewältigt hat. Daher war das Ziel dieses Meetups, einen Weg zu finden, um ein gut vorbereitetes, umsetzbares Produkt-Backlog mit Liberating Structures zu erstellen.

In diesem Zusammenhang waren wir besonders an den drei Themen interessiert, die die „messy middle“ eines jeden Product Backlogs bilden:

1. Der Prozess der Identifizierung potenziell wertvoller neuer Funktionen und notwendiger technischer Arbeiten. Werden „Feature-Anfragen“ immer noch vom „Business“ an die „IT“ weitergegeben, zusammen mit einem Mein-Budget-mein-Feature-Denken, das tendenziell zu lokalen Optimierungen führt?
2. Welche Einträge gehören zu einem bestehenden Product Backlog? Wie reflektiert beispielsweise das Product Backlog nicht-funktionale Elemente, um die Qualität der eingesetzten Technologie zu verbessern?
3. Schließlich, wie geht das Scrum-Team mit dem Refinement des Product Backlog um? Ist es eine Jira-dominierte Übung, während derer Kästchen auf einer Checkliste abgehakt werden? Oder führt das Team alternativ eine offene Diskussion, in welcher der Product Owner das „Warum“ vorbringt, das Entwicklungsteam über das „Wie“ entscheidet und beide sich in der Mitte treffen, um über das „Was“ zu verhandeln?

Mehr zu dem Thema: 28 Product Backlog and Refinement Anti-Patterns.

Liberating Structures Product Backlog: Ecocyle Planning

Das Ecocyle Planning

Der Untertitel der Ecocycle Planning-Seite auf der Liberating-Structures-Webseite fasst das Potential dieser Mikrostruktur gut zusammen:

Analyze the Full Portfolio of Activities and Relationships to Identify Obstacles and Opportunities for Progress.

Meiner Erfahrung nach hat sich Ecocycle Planning als ein mächtiges Werkzeug für Product Owner und Scrum Master erwiesen, wenn ein Scrum Team es mit einem suboptimalen Product Backlog zu tun hat. Es kann als Instrument verwendet werden, um zu verstehen, ob der Inhalt des Product Backlogs noch die bestmögliche Nutzung der Zeit des Scrum Teams widerspiegelt. Darüber hinaus kann das Ecocycle Planning eingesetzt werden, um Prozesse und Praktiken innerhalb von Unternehmen zu identifizieren, die verhindern, dass Product Backlogs ihr volles Potenzial ausschöpfen.

Üungen mit dem Ecocyle Planning

Angesichts der Vielfalt der Teilnehmer am Meetup haben wir in der ersten Übung vier Gruppen gebildet und das Ecocycle Planning genutzt, um eine Liste von Aktivitäten, Praktiken und Beziehungen zu erstellen, die den beruflichen Stand der Teilnehmer bis heute mitprägen haben.

Während diese Übung recht gut funktionierte, ich erwäge, diese Karrierefrage später im Jahr in einem separaten Meetup zu behandeln, war das Ergebnis der abschließenden Übung des Tages verbesserungsfähig. Die vier Gruppen hatten die Aufgabe, Notfallmaßnahmen zu identifizieren, um aus einem schwachen Product Backlog mithilfe eines Strings von Liberating Structures ein umsetzungsfähiges zu machen.

Am Ende schlug eine Gruppe einen Liberating Structures-String vor, die aus den folgenden Mikrostrukturen bestand:

1. Impromptu Networking
2. Ecocycle Planning
3. 15% Solutions
4. 25/10 Crowd Sourcing.

Die Grupppe schlug vor, 1-2-4-All zu nutzen um die individuellen Beiträge zusammenzufassen.

Fazit

Ecocyle Planning ist ein leistungsstarkes forensisches Werkzeug, um Verschwendung, Engpässe, Probleme und Hindernisse innerhalb Ihres Unternehmens und Ihres Product Backlogs zu identifizieren. Üben Sie seine Anwendung in einer kleineren Gruppe, bevor Sie es als Ihr bevorzugtes Moderationswerkzeug für den Rest des Unternehmens einführen. Planen Sie genügend Zeit für Übungen auf der Grundlage der Ecocyle-Planung ein; die erfolgreiche Durchführung eines Ecocyle Plannings mit Anfängern dauert wahrscheinlich viel länger als die geschätzte Dauer von 95 Minuten.

Welche Probleme haben Sie mit Ecocycle Planning gelöst? Bitte teilen Sie uns dies in den Kommentaren mit.

Liberating Structures Product Backlog — Weitere Lektüre

📅 Professional Scrum Master Training PSM I + Liberating Structures — Berlin, 18-20 Februar 2020.

Liberating Structures für Scrum (1): Die Sprint Retrospektive.

Liberating Structures für Scrum (2): Das Sprint Planning.

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.