Wie mache ich aus großen Epics für eine Neu-Entwicklung ein Productbacklog mit Stories, für einen Sprint?

Question

Ich denke man findet viele Informationen dazu, wie ein gutes Productbacklog aufgebaut sein sollte, aber was mache ich, wenn es noch kein Productbacklog gibt, dass es zu pflegen gilt, sondern ein neues Productbacklog erstellt werden muss?

Bei einer Neu-Entwicklung gibt es zu Beginn sehr viele Unbekannte. Um herauszufinden wie ein Produkt aussehen kann, gibt es ebenfalls bereits viele agile Methoden, die helfen sich ein Bild davon zu machen, z.B. Durch Design Thinking oder Design Sprints. Aber wie verarbeite ich die gewonnenen Erkenntnisse so, dass am Ende ein Backlog entsteht? Wie mache ich aus vielen recht großen Epics, kleine Stories, welche ich gut in den Sprint packen kann? Habt ihr hierzu bereits Erfahrungen gemacht oder Methoden?

Answer 1

Ich nutze für solche Situationen immer gerne eine (User) Story Map.

Zuerst überlegt man, welche Aktionen ein User alle macht, wenn er die im Epic beschriebene(n) Funktion(en) nutzen will. Diese sammle ich als Vertikale Abfolge (z.B. mit Klebezettel) an der Wand.
Danach schauen wir, was umgesetzt werden muss, kann und sollte um die jeweiligen Schritte zu ermöglichen, die ein User am Schluss ausführen soll. Diese Punkte sammelt man Vertikal unter dem jeweiligen Schritt, zudem sie gehören. Aus diesen Punkten werden dann die User Stories erarbeitet.

Das ganze erarbeite ich in einem Workshop mit allen Leuten die mir dabei helfen können. (Manchmal ist es auch sinnvoll, das in mehreren Workshops zu machen, da die Gruppe zu groß oder unterschiedlich sein könnte.)
Das ganze bietet die Möglichkeit durch das Ordnen der Zettel auch gleich eine Priorität für die Abarbeitung zu erarbeiten. (A ist wichtiger als B und B muss vor C gemacht werden, usw.) Auch kann man so schon eine erste grobe Release Planung machen.
Allerdings sollte man beachten, dass je größer der gemapte Teil ist, desto mehr oder größere Wände brauche ich auch.

Answer 2

Just stand ich vor der gleichen Aufgabe. Ein leeres Backlog, nur eine Produktvision und sonst nichts. Deshalb haben wir im Team festgelegt, dass die eigentliche Product-Discovery zunächst den wichtigsten und größten Anteil der Arbeit darstellt.

Dazu gehen wir wie folgt vor:

1. Verstehen Deinen Kunden. Wir haben mögliche potentielle Personas identifiziert, die wir gemeinsam ausgearbeitet haben und damit ein gemeinsames Verständnis für die Zielgruppe geschaffen.

2. Als Zweites haben wir ein Event Storming durchgeführt. Dabei hat das Team ausgehend vom übergeordneten Ziel alle möglichen Ereignisse (Event) identifiziert, die auf das große Ziel einzahlen. Diese bringen wir in eine Reihenfolge und erarbeiten abgeleitete sogenannte Commands, die von einem Ereignis zum nächsten führen und diese miteinander verknüpfen. Oftmals werden diese Commands von einer der in 1. erarbeiteten typischen Persona ausgeführt. Die Kombination aus Persona, Command und erreichtes Ereignis stellt alle 3 Teile einer User Story dar.

3. Aus dem Ergebnis des Event Storming bauen wir eine finale Story Map auf, aus der wir dann Release-Slices herausschälen. Dabei kommt es immer wieder vor, dass Stories noch zu groß sind und in zwei kleinere Teile geschnitten werden müssen.

4. Das Release-Slice aus 3 geht dann ins Backlog bzw. erste Sprint-Planning, alles andere niedriger Priorisierte entweder nur in groben Stories oder (aus meiner Erfahrung noch besser) gar nicht ins Backlog. Ich habe gute Erfahrungen damit gemacht, wenn es für ein Produkt einen Ideenspeicher gibt (ich nenne es gerne brilliant ideas) und ein kleines, fokussiertes und managebares Backlog, dass gerade mal die nächsten 3 Sprints füllt.

Answer 3

Als gute Übung, um aus vielen größeren Epics, effektiv kleinere zu schneiden, führe ich oft das Morning Game von Jeff Patton mit den Teilnehmern durch. Damit wird allen Beteiligten sehr anschaulich klar, was nun zu tun ist. Es funktioniert folgendermaßen:

a, Man stelle sich vor, der Wecker klingelt morgen und man möchte in der Arbeit erscheinen. Die Teilnehmer haben die Aufgabe, alle Tätigkeiten auf Stickies zu notieren, die sie normalerweise dafür tun. Also Alles zwischen Aufstehen und Eintreffen am Arbeitsplatz. Dazu kann gehören: Wecker in Schlummerpause, Duschen, Zähne putzen, Frühstücken, Anziehen, Schminken, U-Bahn fahren, Auto fahren, Coffee-To-Go holen etc. etc.

b, Alle Tätigkeiten werden in einer chronologischen Reihenfolge an die Wand geklebt. Ähnliche Tätigkeiten können geclustered werden (z.B. Körperpflege, Fahrt zur Arbeit).

c, Jetzt sollen sich die Teilnehmer vorstellen, dass sie an dem Tag verschlafen hatten, weil der Wecker nicht funktionierte. Sie müssen aber unbedingt pünktlich in der Arbeit zu einem wichtigen Termin erscheinen. An der Wand wird eine Linie gezogen und die Teilnehmer sind aufgefordert, alles was nicht unbedingt nötig ist, unter die Linie umzuhängen. Z.B. kann Duschen ausfallen, aber Zähneputzen nicht. Das Frühstück könnte ausfallen, dafür aber gegen ein belegtes Brötchen beim Bäcker kaufen ersetzt werden.

d, Gemeinsam Reflektieren, wie diese spielerische Verfahrensweise auf das eigene Produkt angewendet werden kann.