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. 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. 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. 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. 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. 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 Runsheets.

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