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.

Agile Toolbox
Scrum
Scrum Artefacts
User Story
Tim Scheumann
November 21, 2018

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?