Was vorher fertig sein muss
Mindestens eine Persona oder ein klares Nutzerverständnis liegt vor, an dem sich die Backbone-Aktivitäten orientieren.
Eine Produkt- oder Release-Vision mit klarem Outcome existiert, gegen die Slices bewertet werden können.
Was vor Start vorliegen muss
Lange Wand oder Miro-Board mit horizontalen Bahnen; vier Farben Stickies (gelb Aktivitäten, blau Tasks, grün Stories, pink Risiken); breite Tische zum Sortieren; Timer; Link zum bisherigen Backlog falls vorhanden.
Ein Facilitator mit Mapping-Erfahrung; Product Owner; zwei bis vier Engineers; ein UX Lead; optional ein Stakeholder aus Vertrieb oder Support. Maximal acht Personen, sonst zerfällt der Fluss.
Nutzer-Persona; Outcome-Hypothese des Produkts oder Releases; bekannte Constraints (Compliance, Plattform, Termine); existierendes Backlog als Eingabe, nicht als Vorgabe.
4-6 h für erste Map, danach 1 h Pflege pro Release
Wand vorbereiten: oben links Persona, dann von links nach rechts Zeitachse für Nutzeraktivitäten (Backbone). Unter Backbone Bahn für Tasks, darunter Bahn für Stories. Rechte Wand für „später“-Park.
Die eine Frage, die diese Methode beantwortet
Welcher schmalste End-to-End-Fluss liefert dem Nutzer den ersten echten Wert und wie sieht der nächste sinnvolle Slice danach aus?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Backbone bauen | 45-60 min | Nutzeraktivitäten chronologisch sammeln (gelb), grobgranular: was tut der Nutzer von Start bis Ziel. Anschließend in Reihenfolge bringen und auf 8-15 Backbone-Schritte verdichten. | Wenn Backbone über 20 Schritte hat, ist die Ebene zu fein. Aktivitäten sind nicht Klicks, sondern Aufgaben („Bestellung aufgeben“, nicht „Button drücken“). |
2Phase 2: Tasks und Stories | 60-90 min | Pro Aktivität die nötigen Tasks (blau) und konkrete Stories (grün) darunter hängen. Stories als kleine Outcome-Schritte, mehrere pro Task möglich. | Stories nicht implementierungslastig formulieren. Wenn eine Story technikspezifisch ist („mit React umsetzen“), gehört das in Tasks, nicht in die Map. |
3Phase 3: Risiken markieren | 20-30 min | Pink-Sticker an Stories mit hoher Unsicherheit oder Abhängigkeit. Pro Risiko kurz notieren, was den Slice gefährdet (technisch, regulatorisch, nutzerseitig). | Wenn alle Stories pink markiert sind, ist die Map zu früh. Erst Discovery-Methoden, dann Map. Nur die wirklich kritischen Risiken markieren. |
4Phase 4: Slices schneiden | 45-60 min | Horizontale Linien quer über die Map: erste Linie für MVP (schmalster Fluss, der echten Wert liefert), zweite für Release 2 etc. Stories über der Linie sind drin, darunter raus. | MVP-Slice muss durch jede Backbone-Aktivität gehen, sonst ist es kein End-to-End. Lieber weniger Tiefe pro Schritt als ganze Schritte weglassen. |
5Phase 5: Validieren und übergeben | 30-45 min | MVP-Slice mit Nutzer-Persona und Vision abgleichen. Kann die Persona ihren Job machen? Stories des Slices in Backlog überführen mit Schätzgröße und Owner. | Wenn die Persona mit dem MVP-Slice ihren Job nicht erledigen kann, ist es kein MVP, sondern ein Teilstück. Slice neu schneiden, bevor das Backlog gefüllt wird. |
Was am Ende rauskommt
Story Map als Foto oder Miro-Board mit Backbone, Tasks, Stories, Risiken und Release-Slices. Begleitend ein Mapping-Doc mit Persona, Outcome-Hypothese, MVP-Definition, Slice-Liste und offenen Risiken.
Map pro Release als eigenen Snapshot ablegen. Beim Backlog-Sync Stories mit Map-ID verknüpfen. Änderungen am Backbone nur über Mapping-Session, nicht im Ticket-System schleichend.
Kompakte Arbeitsvorlage für User Story Mapping mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# User Story Mapping Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Story Map:
- Release Slices:
- Backlog Candidates:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Story Map — Onboarding-Redesign, Mai 2026
**Persona**: Neuer SaaS-Nutzer (Solo-Founder, kein technischer Hintergrund).
**Outcome**: 60% der neuen Nutzer erreichen Aha-Moment in Session 1 (heute 28%).
**Backbone**: Registrieren -> Workspace anlegen -> Erstes Projekt importieren -> Erstes Insight sehen -> Team einladen.
**MVP-Slice (Release 1, bis 30.06.)**:
- Registrieren: Magic Link statt Passwort.
- Workspace anlegen: ein Default-Template, kein Wizard.
- Erstes Projekt: CSV-Upload, max 3 Spalten Auto-Erkennung.
- Erstes Insight: eine vordefinierte Top-3-Visualisierung.
- Team einladen: per E-Mail-Adresse, kein Rollensystem.
**Release 2 (bis 31.07.)**:
- Google/Microsoft SSO.
- Wizard für komplexe Datenquellen.
- Mehrere Visualisierungen wählbar.
- Rollenrechte für Eingeladene.
**Risiken (pink)**:
- CSV-Auto-Erkennung bei mehr als 10 Spalten unsicher (Spike vor Sprint 1, Owner: @ben).
- Magic-Link-Deliverability in Enterprise-Mail (Test in Woche 1, Owner: @anna).Symptome erkennen, gegensteuern
Obere Reihe enthält Namen wie „Dashboard“, „Export-Modul“, nicht Nutzeraktivitäten.
Frage stellen: was tut der Nutzer hier. Backbone-Karte mit Verb formulieren („Bestellung aufgeben“). Featurenamen gehören in Tasks oder Stories darunter.
Slice deckt nur Registrierung und Workspace ab, Nutzer kann seinen Job nicht abschließen.
MVP muss durch jede Backbone-Aktivität gehen, jeweils nur dünn. Lieber zwei Spalten je Aktivität als alle Spalten der ersten zwei Aktivitäten.
Backlog wird im Ticket-System weiterentwickelt, Map wird nicht mehr aktualisiert.
Map als Source of Truth für Scope-Entscheidungen festlegen, Backlog spiegelt. Mapping-Termin alle 2-4 Wochen fix, sonst stirbt das Artefakt.
Map enthält 300+ Stickies, Übersicht geht verloren, neue Personen finden sich nicht zurecht.
Tasks und Stories konsolidieren. Backbone hart auf max 15 Schritte begrenzen. Detail gehört ins Refinement, nicht in die Map.
Slice-Entscheidung erfolgt durch PO allein, Engineering ist nicht eingebunden, Aufwände sind unrealistisch.
Slicing-Phase nur mit Engineering. Pro Slice grobe T-Shirt-Größe gemeinsam schätzen. Wenn Engineering nicht verfügbar, Phase 4 vertagen.
Diskussionen drehen sich um „was wollen wir eigentlich erreichen“, Map wird mehrfach umgebaut.
Vor Mapping eine Vision/Outcome-Hypothese verbindlich setzen. Wenn die Vision unklar ist, erst Product Vision Board, dann Mapping.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.