Wie man einen außer Kontrolle geratenen Product Backlog wieder in einen geordneten Zustand bringt

Agiler Frühjahrsputz: Tipps und Tricks für einen sauberen Product Backlog
Keine Kommentare

Die Feiertage sind vorbei, Zeit für einen Frühjahrsputz! Das gilt nicht nur für das heimische Idyll, sondern auch für Projekte im Arbeitsalltag. Oder genauer gesagt: Es wird höchste Zeit, den Product Backlog zu pflegen. Wie genau man dabei vorgehen sollte, erklärt Daniel Ruckriegel in diesem Artikel.

Stellen wir uns folgendes Szenario vor: Ein Product Backlog wird nicht regelmäßig aufgeräumt und nicht kontinuierlich gewissenhaft gepflegt. Dadurch wurde es über die Zeit ziemlich groß, unstrukturiert und kompliziert. Das hat Konsequenzen: Der Überblick geht verloren; es häufen sich hinfällige und redundante Stories; den Product Backlog ist nicht nach Priorität geordnet; die Informationen in einigen Stories sind veraltet und die Relevanz gehört überprüft. Zudem fehlt dem Product Owner die Einschätzung, wie gut das Team einzelne Stories im Product Backlog bereits versteht und an welcher Stelle noch weiterer Refinement-Bedarf besteht.

Ist erst einmal solch ein Berg von Arbeit entstanden, ist der jeweilige Product Owner nicht zu beneiden. Trotzdem gibt es keinen Grund, die Hoffnung aufzugeben. Folgende Schritte helfen dabei, die Kontrolle zurückzugewinnen:

  • Verschaffe Dir einen Überblick mithilfe von Story Mapping
  • Gruppiere konsequent Themen und Epics
  • Identifiziere Items, die gelöscht werden können
  • Ordne den Product Backlog nach Priorität
  • Schalte den Turbo ein und nutze mit der Methode Team Estimation Game schnell und einfach die gesamte Kapazität des Teams für den Backlog-Frühjahrsputz
  • Bringe durch die Einführung regelmäßiger Refinement-Termine den Product Backlog langfristig unter Kontrolle

Im Folgenden sehen wir uns diese Tipps genauer an.

Erster Tipp: Überblick verschaffen durch Story Mapping

Sind sehr viele Backlog Items in der Listenansicht des Product Backlogs in JIRA oder Excel vorhanden, fällt es schwer, den Überblick zu behalten. Vielen Product Ownern hilft es, ihr Product Backlog zusätzlich als sogenannte „Story Map“ darzustellen. Bei einer Story Map werden die Backlog Items entlang der Customer Journey (auch „Backbone“ oder „Narrative Flow“ genannt) angeordnet und in High-Level-Aktivitäten gruppiert:

Story Map

Darstellung einer Story Map | Daniel Ruckriegel

Dies hat gleich mehrere Vorteile:

  • Die Darstellung verschafft deutlich bessere Übersichtlichkeit.
  • Die Darstellung hilft dabei, ein gemeinsames Verständnis über das Produkt zu schaffen.
  • Die Darstellung hilft dabei, im Gespräch mit Stakeholdern und Anforderungsgebern leichter die Orientierung zu behalten, über welchen Bereich gerade gesprochen wird.
  • Die Gruppierung nach High-Level-Aktivitäten hilft dabei, leichter Themen und Epics abzuleiten.
  • Der Fokus liegt auf der Kundensicht sowie den Wirkungen, die für die Kunden erzielt werden sollen.

Zweiter Tipp: Konsequentes Gruppieren in Themen und Epics

Wenn Du bereits den ersten Tipp umgesetzt hast, ist es bereits viel leichter, auch den nächsten Tipp umzusetzen. Durch die Story-Map-Darstellung wurden allen Backlog Items High-Level-Aktivitäten des Kunden zugeordnet. Hieraus lassen sich Themen und Epics ableiten, in die sich die Backlog Items gruppieren lassen. Gehe nun Deinen Product Backlog durch und prüfe, ob jedes Item einem Epic beziehungsweise Thema zugeordnet ist. Ein gut strukturierter Backlog ist nicht nur übersichtlicher, sondern hilft auch bei der Prüfung auf Vollständigkeit.

Dritter Tipp: Identifikation von Items, die gelöscht werden können

Viele Product Owner haben leider die Angewohnheit, Anforderungen im Product Backlog hinzuzufügen, aber nie wieder zu entfernen – selbst wenn diese nicht mehr von Interesse sind. Um den Umfang des Product Backlogs zu verringern, ist es hilfreich, die Backlog Items auf Hinfälligkeit beziehungsweise Redundanz zu prüfen. Die als hinfällig oder redundant identifizierten Stories sind anschließend zu löschen.

Vierter Tipp: Ordne den Product Backlog nach Priorität

Ein gut priorisierter Product Backlog ist ein entscheidender Erfolgsfaktor in der agilen Produktentwicklung. Mithilfe einer laufenden Priorisierung wird sichergestellt, dass das Team in einem volatilen, schnelllebigen Umfeld die vorhandene Energie und Kapazität in die wirklich wichtigen Themen investiert. Es gibt sehr viele Priorisierungsmethoden wie zum Beispiel MoSCow, Relative Weight, Theme Screening oder WSJF. Welche dieser Methoden Du wählst, ist eher sekundär. Wichtig ist, dass überhaupt eine strukturierte Priorisierung durchgeführt wird. Entscheide dich für eine Methodik und priorisiere ab jetzt regelmäßig.

Fünfter Tipp: Veranstalte einen Workshop für den Frühjahrsputz

Die bisherigen Tipps sind sehr arbeitsintensiv. Nicht in jedem Team kann ein Product Owner diese Aufgaben allein lösen. Glücklicherweise gibt es mit der „Dynamic“-Variante des „Team Estimation Games“ eine erstaunlich zeiteffiziente sowie effektive Methode, um einen großen Teil der Arbeit mit einem Mal in einer konzentrierten Teamaktion abzutragen. Das geballte Wissen des Teams und der parallelisierte Arbeitsablauf des Spiels sorgen dabei für eine hohe Effizienz.

Wie läuft nun der Frühjahrsputz mit dem „Team Estimation Game“ genau ab?

Vorbereitung:

  • Der komplette Product Backlog wird ausgedruckt
    • Bewährt hat sich der Ausdruck jeder Story auf ein DIN A4 Blatt. (Solltest Du mit JIRA arbeiten, hat es sich bewährt, einen Excel-Export des Product Backlogs durchzuführen und mithilfe eines Word-Serienbriefs die Daten als formatierte Story Cards aufzubereiten.)
    • Folgende Felder sollten mindestens ersichtlich sein:
      • Titel
      • Issuetyp
      • Beschreibung
      • Akzeptanzkriterien
      • Weitere, je nach Bedarf
    • Es sollten weitere leere Felder ausgewiesen sein:
      • Größe
      • Hinfällig / Duplikat
      • Refinement – Bedarf
  • Das Team ist mit Product Owner komplett vertreten
  • Der Scrum Master hat eine Skala nach der Fibonacci-Reihe für die Größe und eine Skala für die Priorität (z.B. niedrig, mittel, hoch) vorbereitet

Ablauf:

Runde – Ablegen

  • Der Product Owner verteilt die User Storys möglichst gleichmäßig ans Team aus.
  • Die Estimation wird in stiller Arbeit durchgespielt.
  • Die Teammitglieder lesen ihre User Storys und legen sie auf der Skala zu jener Zahl, die nach Meinung des jeweiligen Teammitglieds die Größe der User Story darstellt.
  • Versteht ein Teammitglied die Story nicht, so kommt diese auf den Stapel „Fragezeichen“.
  • Stellt das Teammitglied fest, dass die Story bereits hinfällig ist oder ein Duplikat darstellt, so wird diese auf den Stapel „Hinfällig / Duplikate“ gelegt.
  • Haben alle Teammitglieder ihre Stories abgelegt, beginnt die zweite Runde.

Runde – Verschieben

  • Die Teammitglieder sehen sich die abgelegten Stories der anderen Teammitglieder an und haben die Möglichkeit Stories zu verschieben.
  • Während des Umsortierens einer User Story gibt das Teammitglied eine kurze (!), diskussionslose Erklärung ab und versieht diese Story mit einem Punkt.
  • Das Spiel wird vom Teamleiter beendet, wenn keine User Storys mehr umsortiert werden oder nichts Neues dabei herauskommt.

Nach dem Spiel bespricht das Team alle Stories mit mehr als zwei Punkten in der Gruppe im Detail und ordnet das Ergebnis gemeinsam ein. Danach kommt der Stapel mit den Fragezeichen an die Reihe. Entweder lässt sich ein gemeinsames Verständnis während des Termins noch ad hoc im Team finden oder der Product Owner kennzeichnet die Story mit „Refinement-Bedarf“ für später.

Somit haben wir in einer konzentrierten Aktion sowohl die Größe der Backlog Items geschätzt als auch Items identifiziert, die hinfällig sind, die ein Duplikat darstellen oder noch weiteren Refinement Bedarf besitzen.

Die letzte Aufgabe für den Product Owner ist es nun, alle ermittelten Werte der Stories im Tool für das Anforderungsmanagement zu aktualisieren. Alle Product Owner, mit denen ich diese Methode bisher durchspielen durfte, waren erstaunt, wie schnell sie mit dem Team zu Ergebnissen gekommen sind.

Das Team Estimation Game lässt sich auch hervorragend für die Priorisierung einsetzen. Hier besteht der Teilnehmerkreis allerdings aus den Stakeholdern und dem Product Owner.

Letzter Tipp:

Mit den vorherigen Tipps haben wir den Product Backlog wieder in einen strukturierten und aktuellen Zustand gebracht. Aber nur eine kontinuierliche Pflege des Product Backlogs hilft diesen Zustand auch zu erhalten. Bewährt haben sich regelmäßige Product-Backlog-Refinement-Termine mit dem gesamten Team bzw. in Kleingruppen. In diesen Terminen, die einen zeitlichen Aufwand von 5 – 10% der Sprint Kapazität einnehmen dürfen, werden laufend Items geschnitten, Akzeptanzkriterien verfeinert, neue Items geschätzt und bestehende Items erneut geschätzt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -