text: Liberating Structures Product Backlog — Berlin Product People GmH
  Blog Agile Liberating Structures für Scrum (3): Das Product Backlog
  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.
  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 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:
  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?
  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?
  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.
  Das Ecocyle Planning
  Der Untertitel der Ecocycle Planning-Seite auf der Liberating-Structures-Webseite fasst das Potential dieser Mikrostruktur gut zusammen:
  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:
  Die Grupppe schlug vor, 1-2-4-All zu nutzen um die individuellen Beiträge zusammenzufassen.
  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
  Tags: Liberating Structures, Liberating Structures String, Product Backlog, Product Backlog Refinement, Scrum