Domain Storytelling erklärt: Bildsprache, Workshop-Ablauf und ein Praxisbeispiel

Wenn Strichmännchen mehr klären als hundert Seiten Lastenheft

Ein Fachbereich beschreibt seinen Ablauf, die Entwicklung nickt, und drei Monate später zeigt die erste Version, dass beide Seiten etwas ganz anderes gemeint haben. Wer zwischen Fachabteilung und IT vermittelt, kennt dieses Muster. Selten liegt es an fehlendem Fachwissen. Meist hat jeder ein anderes Bild im Kopf, und niemand hat es je aufgemalt.

Genau hier setzt Domain Storytelling an. Fachleute erzählen an einem konkreten Beispiel, wie ihre Arbeit abläuft, und jemand zeichnet die Geschichte live mit – mit Figuren, Symbolen und nummerierten Pfeilen. Am Ende hängt ein Bild an der Wand, das alle gemeinsam korrigiert haben.

Kurz gesagt: Domain Storytelling ist eine Workshop-Methode, mit der Fachleute und IT ein gemeinsames Verständnis eines Fachgebiets („Domäne“) erarbeiten. Die Bildsprache kennt nur drei Grundbausteine: Akteure, Arbeitsgegenstände und Aktivitäten. Daraus entstehen Sätze, die man von links nach rechts und in nummerierter Reihenfolge lesen kann.

Woher die Methode kommt

Domain Storytelling ist keine Erfindung aus dem Beratungskatalog, sondern hat eine mehr als 20-jährige Vorgeschichte in der Softwaretechnik an der Universität Hamburg, zunächst unter dem Namen „Kooperationsbild“, später als „exemplarische Geschäftsprozessmodellierung“. Den Namen Domain Storytelling verwenden Stefan Hofer und Henning Schwentner seit 2016. Sie haben die Methode ausgearbeitet und in ihrem Buch „Domain Storytelling“ beschrieben, das 2021 auf Englisch bei Addison-Wesley erschien; die deutsche Ausgabe folgte 2023 bei dpunkt.verlag. Seitdem hat sich der Begriff vor allem in der Community rund um Domain-Driven Design verbreitet.

Domain-Driven Design, kurz DDD, ist ein Ansatz, Software konsequent am Fachgebiet auszurichten: Code und Fachsprache sollen dieselben Begriffe verwenden, große Systeme werden entlang fachlicher Grenzen geschnitten. Wie DDD im Ganzen funktioniert, lesen Sie in unserer Einführung in Domain-Driven Design und Event Storming. Domain Storytelling ist eines der Werkzeuge, mit denen man dort das Fachwissen überhaupt erst sichtbar macht. Die Methode funktioniert aber auch ganz ohne DDD – etwa, um einen Ablauf vor einer Prozessänderung zu verstehen.

Die Bildsprache: Akteure, Arbeitsgegenstände, Aktivitäten

Die Symbolik ist bewusst schlicht. Niemand muss vorher eine Notation lernen, wie es bei UML oder BPMN nötig wäre.

• Akteure: Wer handelt? Das kann eine Person sein, eine Rolle („Sachbearbeiterin“), eine Gruppe oder ein IT-System. Dargestellt werden sie als Figur oder Symbol.
• Arbeitsgegenstände: Womit wird gearbeitet? Ein Formular, eine E-Mail, ein Bescheid, ein Lieferschein, aber auch Abstraktes wie eine Information oder ein Termin.
• Aktivitäten: Was passiert? Ein beschrifteter Pfeil mit einem Verb verbindet Akteur und Arbeitsgegenstand („prüft“, „schickt“, „trägt ein“).

Der Kniff liegt in den nummerierten Sätzen. Jeder Pfeil bekommt eine Nummer, und jede Nummer ergibt einen einfachen Satz nach dem Muster „Akteur – tut etwas – mit einem Arbeitsgegenstand – an jemanden“. Liest man die Nummern der Reihe nach vor, erzählt das Bild die Geschichte noch einmal. Dazu kommen Notizen am Rand für Fragen, Regeln oder Sonderfälle, die man bewusst nicht ins Bild zeichnet.

Ein Beispiel aus der Verwaltung: der Bewohnerparkausweis

Angenommen, eine Stadtverwaltung möchte den Antrag auf einen Bewohnerparkausweis digitalisieren. Bevor jemand ein Online-Formular entwirft, erzählt eine erfahrene Sachbearbeiterin, wie ein typischer Fall heute läuft. Daraus könnten diese Sätze entstehen:

1. Die Anwohnerin füllt den Antrag aus.
2. Die Anwohnerin gibt den Antrag mit Fahrzeugschein am Schalter bei der Sachbearbeiterin ab.
3. Die Sachbearbeiterin prüft die Meldeadresse im Melderegister.
4. Die Sachbearbeiterin prüft im Fahrzeugschein, ob das Fahrzeug auf die Anwohnerin zugelassen ist.
5. Die Sachbearbeiterin legt die Gebühr nach der Gebührenordnung fest.
6. Die Anwohnerin bezahlt die Gebühr an der Kasse.
7. Die Sachbearbeiterin stellt den Parkausweis aus und händigt ihn der Anwohnerin aus.

Schon bei Satz 4 wird es oft interessant. „Und wenn es ein Firmenwagen ist?“, fragt die Moderation. Die Sachbearbeiterin erzählt dann, dass dafür eine Bescheinigung des Arbeitgebers nötig ist. Dieser Sonderfall kommt nicht in dasselbe Bild, sondern als Notiz an den Rand – und später womöglich in eine eigene Geschichte. Genau solche Fragen hätte das Lastenheft vermutlich übersehen. Für das spätere Online-Formular sind sie entscheidend.

Fein oder grob, Ist oder Soll: die Scope-Faktoren

Bevor eine Geschichte beginnt, legt das Team fest, was genau erzählt werden soll. Hofer und Schwentner nennen dafür drei Stellschrauben, die sie Scope-Faktoren nennen:

• Granularität – grob oder fein: Eine grobe Geschichte zeigt das Gesamtbild über mehrere Abteilungen, etwa „vom Antrag bis zum fertigen Parkausweis“. Eine feine zoomt in einen einzelnen Schritt, zum Beispiel in die Prüfung der Unterlagen.
• Zeitpunkt – Ist oder Soll: Erzählt wird entweder, wie es heute läuft, oder wie es künftig laufen soll. Wer gleich mit dem Soll beginnt, übersieht leicht, warum der heutige Ablauf so ist, wie er ist.
• Domain Purity – pur oder digitalisiert: Eine „pure“ Geschichte lässt Software bewusst weg und zeigt nur die fachliche Arbeit. Eine „digitalisierte“ nennt die beteiligten Systeme, etwa das Fachverfahren der Meldebehörde in Satz 3.

Ein naheliegender Weg führt von grob, Ist und pur zu fein, Soll und digitalisiert. So versteht man zuerst die Fachlichkeit und entscheidet erst danach, was eine neue Software übernehmen soll.

So läuft ein Domain-Storytelling-Workshop ab

Ein Workshop braucht wenig Material, aber die richtigen Leute. Typisch sind einige Fachleute, die den Ablauf aus eigener Arbeit kennen, ein paar Zuhörende aus Entwicklung, Fachkonzeption oder Projektleitung und eine Person, die moderiert und zeichnet.

1. Thema und Scope festlegen: Nicht „Wie funktioniert unsere Behörde?“, sondern ein konkreter Fall – „Was passiert, wenn eine Anwohnerin heute einen Parkausweis beantragt?“.
2. Erzählen und mitzeichnen: Die Fachleute erzählen Schritt für Schritt. Die Moderation zeichnet sichtbar für alle und fragt nach: Wer macht das? Womit? Und was passiert danach?
3. Den Normalfall zuerst: Erst der typische Ablauf, Varianten und Fehlerfälle kommen als Notiz an den Rand oder in weitere Geschichten.
4. Zurückerzählen: Am Ende liest die Moderation die Sätze in der Reihenfolge der Nummern vor. Die Fachleute korrigieren, bis die Geschichte stimmt.
5. Festhalten und weiterverwenden: Das Bild wird gespeichert und dient als Grundlage für Anforderungen, User Stories oder den fachlichen Schnitt eines Systems.

Erfahrungsgemäß dauert ein Workshop zu einer einzelnen Geschichte oft nicht länger als ein, zwei Stunden. Wer mehrere Varianten oder Abteilungen abdecken will, plant besser mehrere kurze Termine als einen langen Tag.

Typische Fehler

• Alles in ein Bild packen: Wer jede Ausnahme einzeichnet, bekommt ein Knäuel aus Pfeilen, das niemand mehr lesen kann. Eine Geschichte erzählt einen Fall.
• Zu früh über Technik reden: Sobald es um Datenbanken und Schnittstellen geht, schweigen die Fachleute. Technik gehört frühestens in die digitalisierte Soll-Geschichte.
• Die falschen Leute im Raum: Wer den Ablauf nur vom Hörensagen kennt, erzählt eine Wunschversion. Es braucht die Menschen, die die Arbeit tatsächlich machen.
• Abstrakt statt konkret: „Der Kunde bestellt etwas“ sagt wenig. „Frau Meier bestellt zwei Paletten Fliesen und will sie selbst abholen“ bringt die entscheidenden Fragen auf den Tisch.

Werkzeuge: vom Whiteboard bis Egon.io

Für einen Workshop vor Ort reichen Whiteboard, Stifte und Haftnotizen. Für Remote-Workshops eignen sich digitale Whiteboards wie Miro oder Mural, in denen man Symbole als Vorlage ablegt. Wer damit arbeitet, findet in unserem Seminar Miro Grundlagen den Einstieg in Vorlagen und gemeinsames Arbeiten auf dem Board.

Speziell für die Methode gibt es Egon.io, einen quelloffenen Editor für Domain Stories, der im Browser läuft. Er kennt die Bildsprache, nummeriert die Aktivitäten automatisch und kann eine Geschichte Schritt für Schritt wieder abspielen. Das hilft, wenn jemand ein Bild später ohne Erklärung verstehen soll. Ergebnisse lassen sich als Datei speichern und als Bild exportieren.

Und KI? Inzwischen gibt es Versuche, Workshops mit KI-Assistenten zu unterstützen, etwa um aus einer Mitschrift eine Liste nummerierter Sätze vorzuschlagen. Das kann Zeit sparen, ersetzt aber nicht das Gespräch, in dem die Fachleute die Lücken bemerken. Zudem gehören Mitschriften aus internen Abläufen nicht ungeprüft in einen öffentlichen KI-Dienst. Meine Einschätzung: als Protokollhilfe nützlich, als Ersatz für den Workshop überschätzt.

Domain Storytelling und Event Storming: was der Unterschied ist

Beide Methoden stammen aus dem Umfeld von Domain-Driven Design und werden oft in einem Atemzug genannt. Sie setzen aber an unterschiedlichen Stellen an:

• Event Storming sammelt in großer Runde fachliche Ereignisse („Antrag eingegangen“, „Gebühr bezahlt“) auf Haftnotizen entlang einer Zeitachse. Es eignet sich, um schnell einen Überblick über einen großen Bereich zu bekommen.
• Domain Storytelling erzählt einen konkreten Fall mit handelnden Akteuren nach. Es zeigt besser, wer mit wem und womit zusammenarbeitet, und eignet sich für kleinere Runden.

In der Praxis ergänzen sich beide. Ausführlicher erklärt das der verlinkte Beitrag zu DDD und Event Storming oben.

Was das für Ihre Projekte bedeutet

Domain Storytelling löst kein Projektproblem auf einen Schlag, aber es greift eines der häufigsten an: Missverständnisse zwischen den Menschen, die einen Ablauf kennen, und denen, die Software dafür bauen. Die Methode ist billig, schnell gelernt und braucht keine Lizenz. Sie zwingt zu Konkretheit, und genau daran scheitern viele Anforderungsdokumente.

Überschätzt wird sie, wenn man sie als vollständige Dokumentation versteht. Eine Domain Story zeigt Beispiele, keine vollständigen Regeln. Für Fristen, Berechnungen und Ausnahmen braucht es weiter eine saubere Anforderungsanalyse und Anforderungsdokumentation. Für die meisten Teams lohnt sich der Versuch dennoch: Ein Workshop von zwei Stunden mit zwei, drei Fachleuten zeigt schnell, ob alle wirklich dasselbe meinen.

Wer die Methode im Zusammenhang mit Softwarearchitektur einsetzen möchte, findet im Seminar Domain-Driven Design (DDD) den Weg von der Fachgeschichte zum fachlichen Schnitt eines Systems. Weitere Seminare rund um Entwurf und Entwicklung sammelt das Themengebiet Software Engineering.

Häufige Fragen zu Domain Storytelling

Brauche ich Domain-Driven Design, um Domain Storytelling zu nutzen?

Nein. Die Methode stammt aus dem DDD-Umfeld, funktioniert aber auch für Prozessanalysen, für Anforderungen oder für die Einarbeitung neuer Kolleginnen und Kollegen.

Wer sollte am Workshop teilnehmen?

Vor allem die Menschen, die die Arbeit selbst machen. Dazu einige Zuhörende aus Entwicklung oder Projekt und eine Moderation, die zeichnet. Kleine Runden arbeiten meist konzentrierter als große.

Wie unterscheidet sich eine Domain Story von einem BPMN-Diagramm?

BPMN beschreibt Prozesse vollständig mit Verzweigungen und formaler Notation. Eine Domain Story zeigt einen einzelnen konkreten Fall in einfacher Bildsprache. Sie ist leichter zu verstehen, aber nicht vollständig.

Kann man Domain Storytelling remote durchführen?

Ja. Mit einem digitalen Whiteboard oder mit Egon.io und geteiltem Bildschirm klappt das gut. Wichtig ist, dass alle das Bild sehen, während es entsteht.

Was mache ich mit Sonderfällen?

Als Notiz festhalten und bei Bedarf als eigene Geschichte erzählen. Ein Bild pro Fall bleibt lesbar.