Event Storming ist eine Familie von Formaten mit unterschiedlicher Flughöhe. In der Community haben sich drei Stufen etabliert, die unter anderem das Glossar der DDD-Crew so beschreibt. Du kannst sie nacheinander durchlaufen oder gezielt nur eine Stufe nutzen, je nachdem, welche Frage beantwortet werden soll.
Big Picture Event Storming
Das Big-Picture-Format bildet einen ganzen Geschäftsbereich ab, oft vom ersten Kundenkontakt bis zu Rechnung und Service. Ziel ist ein gemeinsames Verständnis über Abteilungsgrenzen hinweg sowie das Aufdecken von Engpässen, Widersprüchen und Konflikten. Die Notation bleibt bewusst schlank: Domain Events, Hotspots, Akteure, Systeme und Chancen. Das Glossar der DDD-Crew nennt Gruppen von 10 bis über 30 Personen an einer gemeinsamen Papierrolle.
Process Modelling
Process Modelling zoomt in einen einzelnen Prozess hinein. Jetzt kommt eine feste Grammatik ins Spiel: Ein Akteur sieht ein Read Model mit Informationen und löst einen Command aus. Ein System verarbeitet ihn und erzeugt ein Domain Event. Darauf reagiert eine Policy nach dem Muster „Immer wenn X passiert, dann Y" und stößt den nächsten Command an. So wird aus der groben Zeitachse ein lückenloser Prozessfluss, in dem fehlende Regeln und Übergaben auffallen.
Software Design
Im Software-Design-Format geht es um die konkrete Umsetzung innerhalb eines abgegrenzten Teilbereichs. Die Gruppe ergänzt Aggregates, im neueren Sprachgebrauch auch Constraints genannt, also die Stellen, an denen Geschäftsregeln und Konsistenz durchgesetzt werden. Hier arbeiten vor allem Entwicklerinnen, Architekten und ausgewählte Fachexperten zusammen. Commands, Events und Zuständigkeiten lassen sich aus diesem Modell sehr direkt in Code übertragen, etwa in eine ereignisgetriebene Architektur.
Notation: Welche Haftnotiz wofür steht
Die Farben beim Event Storming sind Konventionen und keine verbindliche Norm. Einige gelten in der Community als „offiziell", etwa Orange für Domain Events und Neonpink für Hotspots. Andere variieren je nach Moderation, verfügbarem Material und Werkzeug. Deshalb gehört an jede Workshop-Wand eine sichtbare Legende, die bei neuen Konzepten ergänzt wird.
Kenny Baas-Schwegler beschreibt in seinem Beitrag „EventStorming Core Concepts, Glossary and Legend" die heute verbreitete Belegung, an der sich die folgende Übersicht orientiert. Die Beispiele in der rechten Spalte stammen aus einem fiktiven Maschinenbau-Szenario.
Auffällig ist die Doppelbelegung von Grün für Read Models und Chancen. In der Praxis tauchen Chancen vor allem im Big Picture auf, Read Models erst im Process Modelling, sodass sich beides selten in die Quere kommt. Wichtiger als die exakte Farbe ist ohnehin, dass alle Beteiligten dieselbe Legende vor Augen haben. Ergänzend markieren viele Teams Pivotal Events, also Schlüsselereignisse, mit einer senkrechten Linie und trennen parallele Abläufe in Swimlanes.
Ablauf eines Event-Storming-Workshops Schritt für Schritt
Für ein Big Picture Event Storming hat sich eine Abfolge von Phasen bewährt, die Brandolini in seinem Buch beschreibt und die Moderatoren je nach Gruppe anpassen. Der folgende Ablauf zeigt die typischen Schritte:
- Kick-off: Die Moderation erklärt Ziel und Umfang des Workshops und führt zunächst nur einen Baustein ein, das orangefarbene Domain Event.
- Chaotische Exploration: Alle schreiben parallel und weitgehend schweigend Events auf und kleben sie grob an die Wand. Reihenfolge, Duplikate und Formulierungen spielen noch keine Rolle.
- Zeitachse herstellen: Die Gruppe sortiert die Events von links nach rechts, führt Duplikate zusammen und bringt Formulierungen in die Vergangenheitsform. Pivotal Events gliedern den Fluss in Phasen.
- Hotspots markieren: Jede offene Frage, jeder Widerspruch und jeder Konflikt bekommt eine pinke Notiz. Diskussionen werden geparkt, damit die Gruppe im Fluss bleibt.
- Akteure und Systeme ergänzen: An die Events kommen die beteiligten Rollen und Systeme, etwa ERP, CRM oder Excel-Listen.
- Walkthrough und Reverse Narrative: Eine Person erzählt die Geschichte von links nach rechts, die anderen korrigieren. Beim Rückwärtslesen fragt die Gruppe, was vor jedem Event passiert sein muss, und findet so fehlende Schritte.
- Probleme und Chancen priorisieren: Die Teilnehmenden stimmen ab, welche Hotspots und Chancen zuerst angegangen werden.
- Ergebnis sichern: Fotos der Wand, eine Liste der priorisierten Hotspots mit Verantwortlichen und konkrete nächste Schritte.
Vorbereitung: Raum, Wand, Teilnehmende und Dauer
Ein Event Storming steht und fällt mit der Vorbereitung. Drei Faktoren entscheiden über die Qualität: genug Platz, die richtigen Personen und ein realistischer Zeitrahmen.
Raum und Material
Du brauchst eine lange, freie Wand und eine Papierrolle, denn direkt auf Tapete oder Glas fallen Haftnotizen gern ab. Dazu kommen Haftnotizen in mindestens fünf Farben, dicke Filzstifte für aus der Distanz lesbare Notizen und ein sichtbarer Timer. Viele Moderatoren räumen Tische und Stühle aus dem Wandbereich, damit die Gruppe steht und in Bewegung bleibt. Präsentationsfolien braucht es nicht.
Die richtigen Personen
Brandolini formuliert die Faustregel so: Im Raum sollen Menschen sein, die die richtigen Fragen stellen, und Menschen, die die Antworten kennen, dazu eine neutrale Moderation. Für einen Maschinenbauer heißt das etwa Vertrieb, Konstruktion, Arbeitsvorbereitung, Fertigung, Service, Buchhaltung und IT. Fehlt ein Bereich, bleibt auf der Wand ein weißer Fleck, der später teuer werden kann. Mindestens eine entscheidungsbefugte Person sollte dabei sein.
Dauer
Feste Vorgaben gibt es nicht. Ein Big Picture Event Storming braucht je nach Umfang einen halben bis ganzen Tag, bei komplexen Domänen auch mehrere Tage. Process Modelling und Software Design finden meist in kürzeren, wiederholten Sessions von einigen Stunden statt, jeweils fokussiert auf einen Prozess oder Teilbereich. Plane großzügige Pausen ein, denn intensives Modellieren im Stehen kostet Energie.
Remote Event Storming mit Miro und Co.
Seit verteilte Teams der Normalfall sind, findet Event Storming häufig auf Online-Whiteboards wie Miro, Mural oder Conceptboard statt. Viele dieser Werkzeuge bieten fertige Vorlagen mit Legende. Die Vorteile liegen auf der Hand: unbegrenzter Platz, keine Reisekosten und ein Ergebnis, das sofort digital vorliegt und sich weiterbearbeiten lässt.
Die Nachteile sind ebenso real. Die Energie einer Gruppe vor der Wand lässt sich online schwer herstellen, parallele Gespräche sind kaum möglich und Bildschirmmüdigkeit setzt früh ein. Bewährt haben sich deshalb mehrere kürzere Sessions statt eines Marathontags, virtuelle Pausen, kleinere Gruppen, Breakout-Räume für die chaotische Exploration und ein vorbereitetes Board mit Legende und Beispiel-Notizen.
Lass die Teilnehmenden das Werkzeug vorab kurz ausprobieren, damit die erste halbe Stunde nicht mit Bedienfragen vergeht. Und prüfe bei sensiblen Prozessinformationen vorher Hosting-Standort und Auftragsverarbeitung des gewählten Tools.
Vom Workshop zu Bounded Contexts und Domain-Driven Design
Für die Softwarearchitektur liegt der größte Wert eines Event Stormings in den Grenzen, die an der Wand sichtbar werden. Pivotal Events, Swimlanes und Wechsel der beteiligten Akteure zeigen, wo ein Teilbereich endet und ein anderer beginnt. Besonders aufschlussreich sind Stellen, an denen sich die Sprache ändert: Wenn „Auftrag" im Vertrieb das unterschriebene Angebot meint und in der Fertigung den Fertigungsauftrag, verläuft dort vermutlich eine Grenze.
Solche Bereiche mit eigener, eindeutiger Sprache heißen in DDD Bounded Contexts. Martin Fowler beschreibt das Konzept in seinem Bliki-Eintrag „BoundedContext" als zentrales Muster des strategischen Designs. Die Begriffe auf den orangefarbenen Notizen bilden zugleich die Grundlage für eine gemeinsame Fachsprache, die Ubiquitous Language.
Aus dem Software-Design-Format leiten sich anschließend Aggregates, Commands und Events direkt ab. Events, die Kontextgrenzen überschreiten, werden zu Kandidaten für Integrations-Events zwischen Modulen oder Microservices. Bei der Ablösung von Legacy-Software zeigt die Wand außerdem, welche Teilbereiche sich zuerst herauslösen lassen. Die priorisierten Hotspots wandern als Risiken und offene Fragen ins Backlog oder in eine Discovery-Phase.
Hypothetisches Beispiel: Event Storming bei einem Maschinenbauer
Das folgende Beispiel ist frei erfunden und dient nur der Veranschaulichung. Ein mittelständischer Sondermaschinenbauer plant, seine gewachsene Auftragsabwicklung zu modernisieren. Bevor über Software gesprochen wird, lädt die Geschäftsführung Vertrieb, Konstruktion, Einkauf, Fertigung, Service und IT zu einem Big Picture Event Storming ein. Die Zeitachse reicht von „Anfrage eingegangen" bis „Wartungsvertrag abgeschlossen".
Schnell kristallisieren sich drei Pivotal Events heraus: „Auftrag bestätigt", „Konstruktion freigegeben" und „Maschine abgenommen". Die meisten pinken Hotspots sammeln sich zwischen Auftragsbestätigung und Konstruktionsfreigabe. Kundenänderungen kommen dort per E-Mail an, ohne dass jemand die Auswirkungen auf Preis und Liefertermin prüft. Außerdem zeigt sich, dass Vertrieb und Fertigung mit „Auftrag" Unterschiedliches meinen.
Aus der Wand leitet das Team drei Kandidaten für Bounded Contexts ab: Angebot und Vertrieb, Auftragsabwicklung und Fertigung sowie Service. Im anschließenden Process Modelling für das Änderungsmanagement entsteht eine neue Policy: „Wenn ein Änderungswunsch nach Konstruktionsfreigabe eingeht, Kosten- und Terminprüfung anstoßen". Für das Serviceportal steht als nächster Schritt eine Make-or-Buy-Entscheidung an.
Typische Fehler beim Event Storming
Die Methode wirkt einfach, doch einige Fehler tauchen immer wieder auf und schmälern das Ergebnis deutlich:
- Falsches Format für die Frage: Wer im Big Picture schon Aggregates und Policies einführt, überfordert Fachleute und verliert den Überblick.
- Unvollständige Gästeliste: Sitzen nur IT-Leute im Raum, entsteht ein Modell, das auf Annahmen beruht.
- Zu wenig Platz: Eine kurze Wand oder ein kleines Board begrenzt das Denken und erzeugt künstliche Enge.
- Aktivitäten statt Events: „Angebot erstellen" ist ein Command. Ohne konsequente Vergangenheitsform verschwimmen Ursache und Ergebnis.
- Hotspots sofort ausdiskutieren: Lange Grundsatzdebatten rauben der Gruppe Energie. Markieren, parken und später klären.
- Moderation mit eigener Agenda: Wer als Moderator Inhalte vorgibt, bestätigt nur die eigene Sicht.
- Kein Follow-up: Ohne Fotos, Verantwortliche und nächste Schritte verpufft das Ergebnis.
- Die Wand als Spezifikation missverstehen: Event Storming ersetzt kein Lastenheft, liefert aber eine belastbare Grundlage dafür.
Häufige Fragen zu Event Storming
Was unterscheidet Event Storming von BPMN?
BPMN ist eine standardisierte Notation, die exakte, oft ausführbare Prozessmodelle erzeugt und meist von Spezialisten am Rechner erstellt wird. Event Storming ist ein Gruppenformat mit bewusst einfacher Notation, das gemeinsames Verständnis und offene Fragen in den Vordergrund stellt. Beide schließen sich nicht aus: Die Ergebnisse eines Event Stormings lassen sich später in BPMN präzisieren.
Wie viele Personen sollten teilnehmen?
Das hängt vom Format ab. Ein Big Picture lebt von der Breite und kann laut DDD-Crew auch mit über 30 Personen funktionieren, sofern genug Wandfläche und Moderation vorhanden sind. Process Modelling und Software Design arbeiten mit kleineren Gruppen, die einen konkreten Prozess oder Teilbereich vertieft bearbeiten.
Brauche ich Domain-Driven Design für Event Storming?
Nein. Big Picture und Process Modelling funktionieren auch ohne DDD-Kenntnisse, etwa zur Prozessanalyse oder zur Vorbereitung einer Softwareauswahl. Erst im Software-Design-Format helfen DDD-Begriffe wie Aggregate oder Bounded Context, das Ergebnis in eine Architektur zu übersetzen.
Funktioniert Event Storming auch remote?
Ja, mit Online-Whiteboards wie Miro oder Mural. Plane mehrere kürzere Sessions mit Pausen, bereite das Board mit Legende vor und nutze Breakout-Räume, damit alle zu Wort kommen.
