Meine Session planen

# 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“). Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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