Von der Story Map ins Backlog – eine Wegbeschreibung

Wie in meinem letzten Blog-Beitrag angekündigt, möchte ich nun genauer darauf eingehen, wie aus einer Story Map mithilfe von Epics und User Storys ein initiales Product Backlog wird.Die Story Map ist also fertig. Nachdem die Wand nun in bunten Post-its erstrahlt, ist es an der Zeit, ein minimal funktionierendes Produkt (engl. Minimum Viable Product – MVP) festzulegen. Dazu nimmt man am besten ein dickes, leuchtendes Klebeband und zieht eine Linie von links nach rechts. Jetzt geht es ans Aussortieren und Priorisieren. Oben bleiben die wirklich essenziellen Funktionen sowie Ideen und nach unten wandert alles, was vorerst Zukunftsmusik ist. Das heißt: Man sollte hier danach fragen, was es wirklich braucht, damit man das Produkt End-to-End funktionsfähig vor dem Kunden präsentieren und Feedback einholen kann.Sobald wir festgelegt haben, was ein erster Prototyp (MVP) beinhalten soll, können wir die User Storys schreiben.Dazu nimmt man sich den ersten Post-it und legt los. Man schreibt die User Story nach der bekannten Syntax: „Als … (User) möchte ich … (Funktion), sodass ich ... (Nutzen) habe.“ Meine Kollegin Andra hat dieser Thematik einen ausführlicheren Blog-Artikel gewidmet, den ich an dieser Stelle sehr empfehlen kann.

Was gute User Storys ausmacht

Für gewöhnlich kommt man schnell an einen Punkt, an dem die User Story, welche gerade geschrieben wird, irgendwie zu groß wirkt. Wir sprechen in diesem Fall von einem Epic, aus dem wir mehrere kleinere User Storys ableiten. Dafür haben sich unter anderem folgende Maßnahmen bewährt:

• Mehrere Workflows auf einen minimalen Workflow herunterbrechen
• Verschiedene Operationen separieren
• Komplexe Schnittstellen in einer ersten, simpleren Version erstellen
• Nicht-funktionale Anforderungen erstmal nachlagern
• Komplexität abbauen und auf den Kern reduzieren

Ein praktischer Indikator für die richtige User-Story-Qualität sind die INVEST-Kriterien. Dazu schaut man sich die User Storys an und analysiert diese nach folgenden Kriterien:

• Independent – unabhängig: Die User Story sollte nicht von anderen abhängen.
• Negotiable – verhandelbar: Die User Story ist nicht komplett ausspezifiziert und somit schnell und einfach anpassbar.
• Valuable – werterzeugend: Die Umsetzung soll den Wert des Produkts für den Endkunden steigern.
• Estimable – schätzbar: Die Story muss schätzbar sein.
• Small – klein: Der Arbeitsaufwand sollte sich nur auf einige Arbeitstage beschränken
• Testable – überprüfbar: Die Story ist technisch testbar und kann anhand von Akzeptanzkriterien verifiziert werden.

Starten Sie mit einem kompakten Product Backlog

Ich empfehle, zunächst mit maximal 60 User Storys und einer eindeutigen Priorisierung zu starten. Warum? Sobald es nach dem ersten Sprint Feedback gibt, erübrigen sich ggf. viele User Storys und durch das Feedback kommen neue hinzu. Und da beim agilen Arbeiten immer das Kundenfeedback im Mittelpunkt steht, sind genau diese neuen Storys die entscheidenden.Mit diesem Vorgehen entsteht in kürzester Zeit ein initiales und kompaktes Product Backlog. Dieses kann im Nachgang geschätzt und geschärft werden und dient so als perfekte Grundlage, um einen ersten Forecast zu erstellen und das minimal funktionierende Produkt in die Realität umzusetzen.