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:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen