Was vorher fertig sein muss
Ein konkreter, repräsentativer Geschäftsfall ist ausgewählt und mit den Fachexperten abgestimmt, der typische Aktoren und Übergaben enthält.
Die wichtigsten Aktoren der Story sind identifiziert und die richtigen Personen aus den jeweiligen Bereichen sind im Raum.
Was vor Start vorliegen muss
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.
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.
Ausgewählte Story als ein Satz; bekannte Aktoren; relevante Dokumente oder Systeme, die in der Story vorkommen; offene Fragen aus vorherigen Sessions.
1-2 h
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.
Die eine Frage, die diese Methode beantwortet
Wie läuft dieser Geschäftsfall heute wirklich ab, wer beteiligt sich wann womit, und wo entstehen Reibung oder Übersetzungsfehler?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Story-Auswahl bestätigen | 5 min | 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. | Mischformen vermeiden. Eine Story ist entweder As-Is oder To-Be, nicht beides. Sonst beschreibt das Diagramm einen nicht existierenden Zustand. |
2Phase 2: Story zeichnen (erster Durchgang) | 30-45 min | 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. | Bei Verzweigungen Annotation („manchmal“, „wenn X“). Mehr als 15-20 Pfeile deuten auf zu feine Granularität, dann Story aufteilen. |
3Phase 3: Verfeinerung und Rückfragen | 20-30 min | Zweiter Durchgang mit Klärfragen. Unklare Übergaben, Sonderfälle und Workarounds markieren. Pain Points als rote Annotation. Glossar-Begriffe extrahieren. | Pain Points sind das wertvollste Ergebnis. Wenn keine entstehen, fragt der Moderator gezielt nach Ausnahmen, manueller Nacharbeit und Eskalationen. |
4Phase 4: Sprache und Regeln extrahieren | 15-20 min | 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“). | Wenn dasselbe Wort in verschiedenen Aktivitäten unterschiedliche Bedeutung hat, explizit notieren. Das ist meist ein Hinweis auf einen Context-Wechsel. |
5Phase 5: Snapshot und Followup | 10 min | Foto oder Export des Diagramms. Pain Points priorisieren, Owner zuweisen. Folge-Stories planen (Nachbarprozesse, To-Be-Variante, Sonderfälle). | Eine Story selten genug. Plane mindestens 3 Stories pro Domain, sonst zeigt das Bild nur einen Ausschnitt und Schlüsse sind verzerrt. |
Was am Ende rauskommt
Domain-Story-Diagramm (Bild oder egon.io-Datei) mit numerierten Aktivitäten, Glossar-Anhang mit Domain-Begriffen und Pain-Point-Liste mit Owner und Folgefragen. Abgelegt im Domain-Wiki oder Architektur-Repo.
Pro Story eine eigene Datei mit Datum, Erzähler und Story-Titel. Bei Folge-Workshops neue Version, alte behalten (zeigt Veränderung über Zeit). Glossar konsolidiert über Stories hinweg in eigener Datei.
Kompakte Arbeitsvorlage für Domain Storytelling mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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.Konkret gefülltes Szenario
## Domain Story — „Kundin reklamiert defektes Paket“ (As-Is, 2026-05-18)
**Erzähler**: @sabine (Customer Service Lead)
**Story (12 Aktivitäten)**:
1. Kundin → ruft an → Service Hotline
2. Service-Agent → öffnet → CRM-System (sucht Bestellung)
3. Service-Agent → erfragt → Schadensbeschreibung von Kundin
4. Service-Agent → fotografiert (mündlich) → Beschreibung in Freitext-Notiz
5. Service-Agent → entscheidet → Erstattung vs. Ersatzversand (Heuristik im Kopf)
6. Bei Ersatz: Service-Agent → erstellt → neue Bestellung im Shop-Backend
7. Service-Agent → sendet → Retourenlabel via E-Mail an Kundin
8. (Warten 3-7 Tage)
9. Wareneingang → empfängt → Retourenpaket
10. Wareneingang → prüft visuell → Defekt-Bestätigung
11. Bei Bestätigung: Buchhaltung → bucht → Wareneingang ein
12. Bei Streitfall: eskaliert an Service-Manager (manueller Slack-Ping)
**Pain Points**:
- Pink #1 (Aktivität 5): Heuristik für Erstattung vs. Ersatz nicht dokumentiert, Agenten entscheiden unterschiedlich. Owner: @sabine.
- Pink #2 (Aktivität 12): Eskalation über Slack ohne Trail. Owner: @marcus.
- Pink #3 (Aktivitäten 4 + 10): Schadensbeschreibung und visuelle Prüfung nicht verknüpft, kein gemeinsames Schadensprotokoll.
**Glossar-Auszug**: Erstattung, Ersatzversand, Retourenlabel, Wareneingang, Schadensbeschreibung, Streitfall.Symptome erkennen, gegensteuern
Erzähler beginnt mit „Normalerweise würde der Kunde …“ statt „Frau Meyer hat am Montag …“.
Moderator unterbricht und fordert konkreten Fall mit echten Namen oder mindestens echtem Datum. Generische Stories sind Idealbilder, die in der Realität nicht vorkommen.
Während der Story springt der Erzähler zwischen „so ist es“ und „so sollte es sein“.
As-Is und To-Be strikt trennen. Aktuelle Story zuerst zeichnen, To-Be als separate Story im selben oder Folge-Workshop.
30+ Aktivitäten in einer Story, jeder Klick wird gezeichnet.
Granularität anheben: nur Übergaben zwischen Actors und wesentliche Werteschöpfungs-Schritte. Klicks gehören in UX-Doku, nicht in Domain-Story.
Story läuft glatt durch, keine Reibung, keine Ausnahmen.
Moderator fragt gezielt: was läuft schief? Wann muss eskaliert werden? Welche Workarounds gibt es? Eine reibungsfreie Story ist unrealistisch.
Story wird von jemandem erzählt, der den Prozess nicht selbst macht (z. B. Manager statt Operator).
Workshop pausieren, richtige Person dazuholen. Hörensagen produziert geschönte oder erfundene Stories. Wenn nicht verfügbar, vertagen.
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.