Session Brief: User Story Mapping

Ziel

Artefakt: Story Map

Arbeitsfrage

Welcher schmalste End-to-End-Fluss liefert dem Nutzer den ersten echten Wert und wie sieht der nächste sinnvolle Slice danach aus?

Kontext

Nutzer-Persona; Outcome-Hypothese des Produkts oder Releases; bekannte Constraints (Compliance, Plattform, Termine); existierendes Backlog als Eingabe, nicht als Vorgabe.

Setup

• Format: Methoden-Session
• Dauer: 4-6 h für erste Map, danach 1 h Pflege pro Release
• Modus: Workshop
• Teilnehmende: 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.
• Owner: Ein Facilitator mit Mapping-Erfahrung
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Story Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

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.

Vorbereitung

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.

Agenda

1. Phase 1: Backbone bauen (45-60 min) Owner: Facilitator Aktion: 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. Hinweis: Wenn Backbone über 20 Schritte hat, ist die Ebene zu fein. Aktivitäten sind nicht Klicks, sondern Aufgaben („Bestellung aufgeben“, nicht „Button drücken“). Output: Story Map

2. Phase 2: Tasks und Stories (60-90 min) Owner: Facilitator Aktion: 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. Hinweis: Stories nicht implementierungslastig formulieren. Wenn eine Story technikspezifisch ist („mit React umsetzen“), gehört das in Tasks, nicht in die Map. Output: Release Slices

3. Phase 3: Risiken markieren (20-30 min) Owner: Facilitator Aktion: Pink-Sticker an Stories mit hoher Unsicherheit oder Abhängigkeit. Pro Risiko kurz notieren, was den Slice gefährdet (technisch, regulatorisch, nutzerseitig). Hinweis: Wenn alle Stories pink markiert sind, ist die Map zu früh. Erst Discovery-Methoden, dann Map. Nur die wirklich kritischen Risiken markieren. Output: Backlog Candidates

4. Phase 4: Slices schneiden (45-60 min) Owner: Facilitator Aktion: 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. Hinweis: 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. Output: Story Map

5. Phase 5: Validieren und übergeben (30-45 min) Owner: Owner Aktion: 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. Hinweis: 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. Output: Release Slices

6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Story Map

Abschluss

• Ergebnisartefakt aktualisieren: Story Map
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Story Map: User Story Mapping

Arbeitsfrage

Welcher schmalste End-to-End-Fluss liefert dem Nutzer den ersten echten Wert und wie sieht der nächste sinnvolle Slice danach aus?

Kontext

Nutzer-Persona; Outcome-Hypothese des Produkts oder Releases; bekannte Constraints (Compliance, Plattform, Termine); existierendes Backlog als Eingabe, nicht als Vorgabe.

Beteiligte

• Owner: Ein Facilitator mit Mapping-Erfahrung
• Teilnehmende: 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.

Input

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.

Vorlage

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.

Fertigstellungscheck

• Story Map ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren