Meine Session planen

# Session Brief: Domain Storytelling

## Ziel
Artefakt: Domain Story

## Arbeitsfrage
Wie läuft dieser Geschäftsfall heute wirklich ab, wer beteiligt sich wann womit, und wo entstehen Reibung oder Übersetzungsfehler?

## Kontext
Ausgewählte Story als ein Satz; bekannte Aktoren; relevante Dokumente oder Systeme, die in der Story vorkommen; offene Fragen aus vorherigen Sessions.

## Setup
- Format: Methoden-Session
- Dauer: 1-2 h
- Modus: Workshop
- Teilnehmende: Ein Moderator, der die Story zeichnet und Rückfragen stellt; ein bis zwei Domain-Experten als Erzähler; ein bis drei Entwickler oder weitere Stakeholder als Zuhörer und Klärer; ein Scribe für Glossar.
- Owner: Ein Moderator, der die Story zeichnet und Rückfragen stellt
- 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 Domain Story hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Whiteboard oder digitales Board (Miro mit Domain-Storytelling-Template, egon.io); Piktogramme für Actors (Strichmännchen) und Work Objects (Dokumente, Datenbanken, Briefe); nummerierte Pfeile (1-15) für Aktivitäten; Kamera für Snapshots.

## Vorbereitung
Board horizontal nutzen, links der erste Actor. Notation erklären (Actor, Work Object, nummerierte Pfeile, Annotationen). Regel: Story wird in einem Durchlauf gezeichnet, dann verfeinert. Erzähler beschreibt, Moderator zeichnet.

## Agenda
1. Phase 1: Story-Auswahl bestätigen (5 min)
   Owner: Facilitator
   Aktion: Vorab gewählte Story laut wiedergeben. Granularität klären (Coarse-Grained, Fine-Grained, As-Is, To-Be). Notation am Beispiel des ersten Schrittes demonstrieren. Hinweis: Mischformen vermeiden. Eine Story ist entweder As-Is oder To-Be, nicht beides. Sonst beschreibt das Diagramm einen nicht existierenden Zustand. 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: Domain Story

2. Phase 2: Story zeichnen (erster Durchgang) (30-45 min)
   Owner: Facilitator
   Aktion: Domain-Experte erzählt linear, Moderator zeichnet parallel. Pro Aktivität: Actor + nummerierter Pfeil + Work Object + ggf. Empfänger-Actor. Keine Unterbrechungen für Detaildebatten in diesem Durchgang. Hinweis: Bei Verzweigungen Annotation („manchmal“, „wenn X“). Mehr als 15-20 Pfeile deuten auf zu feine Granularität, dann Story aufteilen. 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: Glossary Notes

3. Phase 3: Verfeinerung und Rückfragen (20-30 min)
   Owner: Facilitator
   Aktion: Zweiter Durchgang mit Klärfragen. Unklare Übergaben, Sonderfälle und Workarounds markieren. Pain Points als rote Annotation. Glossar-Begriffe extrahieren. Hinweis: Pain Points sind das wertvollste Ergebnis. Wenn keine entstehen, fragt der Moderator gezielt nach Ausnahmen, manueller Nacharbeit und Eskalationen. 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: Process Narrative

4. Phase 4: Sprache und Regeln extrahieren (15-20 min)
   Owner: Facilitator
   Aktion: Begriffe für die Ubiquitous Language sammeln (Actor-Namen, Work-Object-Namen, Domain-Verben). Implizite Regeln aus der Story als kurze Sätze festhalten („Eine Bestellung wird storniert, wenn die Zahlung nach 7 Tagen nicht eingeht“). Hinweis: Wenn dasselbe Wort in verschiedenen Aktivitäten unterschiedliche Bedeutung hat, explizit notieren. Das ist meist ein Hinweis auf einen Context-Wechsel. 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: Domain Story

5. Phase 5: Snapshot und Followup (10 min)
   Owner: Owner
   Aktion: Foto oder Export des Diagramms. Pain Points priorisieren, Owner zuweisen. Folge-Stories planen (Nachbarprozesse, To-Be-Variante, Sonderfälle). Hinweis: Eine Story selten genug. Plane mindestens 3 Stories pro Domain, sonst zeigt das Bild nur einen Ausschnitt und Schlüsse sind verzerrt. 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: Glossary Notes

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: Domain Story

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

# Domain Story: Domain Storytelling

## Arbeitsfrage
Wie läuft dieser Geschäftsfall heute wirklich ab, wer beteiligt sich wann womit, und wo entstehen Reibung oder Übersetzungsfehler?

## Kontext
Ausgewählte Story als ein Satz; bekannte Aktoren; relevante Dokumente oder Systeme, die in der Story vorkommen; offene Fragen aus vorherigen Sessions.

## Beteiligte
- Owner: Ein Moderator, der die Story zeichnet und Rückfragen stellt
- Teilnehmende: Ein Moderator, der die Story zeichnet und Rückfragen stellt; ein bis zwei Domain-Experten als Erzähler; ein bis drei Entwickler oder weitere Stakeholder als Zuhörer und Klärer; ein Scribe für Glossar.

## Input
Whiteboard oder digitales Board (Miro mit Domain-Storytelling-Template, egon.io); Piktogramme für Actors (Strichmännchen) und Work Objects (Dokumente, Datenbanken, Briefe); nummerierte Pfeile (1-15) für Aktivitäten; Kamera für Snapshots.

## Vorlage
# Domain Storytelling Arbeitsvorlage

## Ziel

Piktografische Methode, um Geschäftsprozesse als konkrete Stories zu modellieren.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Domain Story:
- Glossary Notes:
- Process Narrative:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Domain Story 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