Die Geschichte eines Produkts von links nach rechts, in Releases geschnitten mit Schnittlinie.
1 Beispiel: User-Story-Map
Story-Map der Berichtsfunktion
Vier Aktivitäten einer Berichtsfunktion, geschnitten in MVP, ein zweites Release und später.
Spalten sind die Geschichte in Erzählreihenfolge, Zeilen sind Release-Schnitte. Die Schnittlinie unter dem MVP ist der redaktionelle Punkt, und die eine riskante Story, Berechtigungen auf Zeilenebene, ist markiert, bevor sich jemand auf den Termin festlegt.
Eine User-Story-Map ordnet die User Storys eines Produkts in zwei Dimensionen. Die Methode stammt von Jeff Patton. Von links nach rechts läuft das Backbone: die Aktivitäten eines Nutzers in Erzählreihenfolge. Darunter stehen die Storys, nach Priorität von oben nach unten.
Waagerechte Schnittlinien teilen die Map in Releases. Alles über der ersten Linie ist das MVP, ein durchgehender Weg durch das ganze Produkt, auch wenn jeder Schritt nur minimal umgesetzt ist.
Wann eine User-Story-Map sinnvoll ist
Beim Zuschnitt eines MVP, wenn das Team entscheiden muss, was in den ersten Release gehört.
Wenn ein flaches Backlog mit hundert Tickets den Blick auf den gesamten Nutzerweg verloren hat.
Nicht für die Terminplanung über Teams hinweg: Fristen und Abhängigkeiten zeigt ein Gantt-Diagramm.
So erstellst du eine gute User-Story-Map
Formuliere das Backbone mit Verben aus Nutzersicht, etwa „Bericht erstellen“.
Sorge dafür, dass jedes Release jede Aktivität des Backbones abdeckt.
Zeichne die Schnittlinie deutlich, sie ist die eigentliche Entscheidung.
Markiere riskante Storys, bevor sich jemand auf einen Termin festlegt.