So führst du ein erfolgreiches virtuelles Eventstorming durch
So führst du ein erfolgreiches virtuelles Eventstorming durch
Nachdem wir im letzten Artikel gezeigt haben, wie du ein virtuelles Brainstorming effektiv umsetzt, widmen wir uns heute dem Eventstorming. Erfahre, wie du diese kreative Methode online durchführst, welche Vorbereitungen nötig sind, und profitiere von unseren umfangreichen Erfahrungen. Zum Abschluss wartet ein praxisnahes Fallbeispiel auf dich!
Was ist Eventstorming eigentlich?
Eventstorming ist eine kreative Methode, die wir nutzen, um Software zu entwerfen und ein gemeinsames Big Picture unserer Produkte zu erhalten. Obwohl Eventstorming auch in anderen Bereichen wie der Geschäftsprozessentwicklung eingesetzt werden kann, konzentrieren wir uns hier auf die Softwareentwicklung. Das Ziel von Eventstorming ist es, eine Programvision so weit zu detaillieren, dass konkrete Entwicklungsaufgaben daraus abgeleitet werden können.
Wichtig: Wir beschreiben in diesem Artikel unsere Erfahrungen mit einer für uns angepassten Eventstorming-Methode. Beispielsweise verwenden wir Skizzen zur Visualisierung und spielen Arbeitsabläufe aus Benutzersicht durch. Diese Vorgehensweise hat sich für uns bewährt, und wir möchten unsere Erfahrungen mit dir teilen.
Die Grundidee von Eventstorming
Jede Interaktion mit einem Programm kann als Auslöser für ein Event verstanden werden. Ein Event beschreibt dabei die Änderung, die durch die Interaktion entstanden ist – es repräsentiert Fakten innerhalb des Systems. Klickst du zum Beispiel in deinem Textverarbeitungsprogramm auf die „Speichern“-Schaltfläche, wird das Dokument gespeichert und das Event „Textdokument wurde auf Festplatte gespeichert“ erzeugt. Das Event beschreibt also die Zustandsänderung durch eine Aktion.
Dieses konkrete Event zeigt, dass du zum Ausführen eine Schaltfläche benötigst. Aus dieser Änderung können weitere Aktivitäten entstehen: Prozesse werden gestartet, Aktionen ausgeführt. Indem du Aktionen und Events durchspielst, erhältst du ein umfassendes Bild davon, wie dein Programm verwendet werden könnte.
Vielleicht denkst du jetzt, dass das nicht neu ist, schließlich gibt es bereits User Stories wie: „Als Nutzer möchte ich mein Textdokument auf der Festplatte speichern können.“ Der Unterschied beim Eventstorming ist jedoch, dass du nicht nur die Nutzersicht betrachtest. Was ist mit dem Softwareentwickler, dem Designer und all den anderen Stakeholdern? Was sollen sie genau tun? Braucht es ein Interface, eine Schaltfläche?
Eventstorming zeichnet ein detailliertes Bild deines Programms und bezieht alle Interessensgruppen mit ein. Es ist also besonders geeignet, wenn Menschen mit unterschiedlichen Perspektiven und Expertisen in deinem Workshop zusammenkommen. Nach dem Workshop hat jeder die Möglichkeit, konkrete Arbeitsaufgaben abzuleiten.
So führst du ein Eventstorming durch
Beim Eventstorming unterscheiden wir drei Phasen:
- Phase – Überblick schaffen: Ihr erstellt eine Übersicht und klärt, welche Personen und Ziele relevant sind.
- Phase – Konkret werden: Fokus auf Prozesse, Interaktionsmöglichkeiten, Kommandos und die konkrete Anwendung.
- Phase – Systemdesign: Hinzufügen von Aggregaten und Ableitung einer Kontextmap (externer Link).
Wir erwähnen die dritte Phase der Vollständigkeit halber, behandeln sie aber nicht ausführlich. Unser Ziel ist es, ein gemeinsames Verständnis für das Software-Design und die Systemlandschaft zu erzeugen, was wir bereits nach Phase 2 erreichen. Daher konzentrieren wir uns in diesem Artikel auf die ersten beiden Phasen.
Für jede Phase verwenden wir farblich unterschiedliche Klebezettel. Als wir zum ersten Mal Eventstorming durchgeführt haben, benötigten wir eine riesige Wand und hunderte Klebezettel. Mittlerweile nutzen wir virtuelle Whiteboards mit elektronischen „Klebezetteln“. Eine große Auswahl an Open-Source-Whiteboards findest du hier. Wenn du weitere Informationen oder Tools für Eventstorming suchst, wirst du hier fündig.
Phase 1: Verschafft euch einen Überblick
In Phase 1 geht es darum, einen umfassenden Überblick zu erhalten. Wir verwenden folgende Klebezettelfarben:
- Orange für Events
- Gelb für Akteure (z.B. Personen)
- Rosa für externe Systeme (Bereiche, mit denen das Programm interagiert, die aber nicht Teil des Programms sind, z.B. ein externer Cloudspeicher)
Konzentriert euch darauf, wie euer System genutzt wird und welche relevanten Events sich daraus ableiten. Schreibt diese Events auf die orangenen Klebezettel. Oft entsteht beim Nachdenken über eine Aktion automatisch die nächste, und ihr „spielt“ euer Programm mehrmals durch.
Nehmen wir das Beispiel mit der Textverarbeitungssoftware und dem Speichern-Befehl. Der Benutzer klickt auf den Speichern-Button, wodurch sich die Oberfläche zum Speichern öffnet. In Events (orange) ausgedrückt könnte es wie folgt aussehen (Achtung: Beispiel enthält Fehler, Auflösung folgt):
Ähnlich wie beim Brainstorming geht es auch hier darum, viele Event-Ideen zu sammeln. Allerdings machen wir Eventstorming zielgerichtet – Funktionalitäten, die wir im ersten Schritt nicht umsetzen wollen, nehmen wir nicht mit auf. Ihr könnt aber auch alle Ideen durchdenken, um unerwartete, leicht umzusetzende Features zu entdecken. Achtet jedoch darauf, euch nicht zu verzetteln, denn die Übersicht wird schnell sehr groß.
In dieser ersten Phase können auch externe Systeme vorkommen. Wenn ihr das Textdokument beispielsweise nicht auf die Festplatte, sondern auf einen Onlinespeicher schreiben wollt, ist dieser nicht Teil eures Systems und wird daher auf einen rosa Zettel geschrieben. Relevante Events, die vom externen System an euer System übergeben werden, wie „Datei wurde durch einen anderen Benutzer gesperrt“, nehmt ihr mit auf.
Nachdem ihr alle Funktionsmöglichkeiten eures Programms durchgedacht habt, werden sich viele Klebezettel auf eurer (hoffentlich virtuellen) Wand befinden.
Phase 2: Werdet konkret!
In Phase 2 verwenden wir weitere Farben:
- Grün für Eingaben bzw. Ansichten
- Blau für Kommandos
- Lila für Regeln
Das Ziel dieser Phase ist es, die Schritte zu modellieren, die zu einem Event führen. Am Ende habt ihr eine sehr konkrete Vorstellung von dem Programm, das ihr entwickeln wollt.
Schritt für Schritt zum konkreten Modell
- Ansicht hinzufügen: Zieht den Klebezettel für den Benutzer und das folgende Event auseinander. Zwischen Benutzer und Event platziert ihr einen grünen Klebezettel. Dort notiert ihr das Interface, das der Benutzer sieht und mit dem er interagiert. Es hilft, das Interface mit relevanten Interaktionsmöglichkeiten zu skizzieren. So haben alle Teilnehmer sofort eine Vorstellung davon, worüber gerade diskutiert wird. Beispiel:
- Kommando hinzufügen: Dem grünen Klebezettel folgt ein blauer. Darauf notiert ihr das Kommando, das zum Event führt, z.B. „Dokument auf Festplatte speichern“. Visualisierung:
Dabei fällt auf, dass das Event „Speicher-Button gedrückt“ entfernt wurde. Das Drücken des Buttons selbst ist keine Änderung im System, sondern führt nur zu einer visuellen Änderung. Beim Start von Phase 2 werdet ihr wahrscheinlich feststellen, dass sich solche falschen „Events“ eingeschlichen haben. Mit der Zeit lernt ihr, diese zu erkennen und auszuschließen. Überlegt immer, ob eine tatsächliche Änderung im System stattfindet.
- Regeln hinzufügen: Jetzt kommen die lila Klebezettel ins Spiel. Sie repräsentieren Regeln, die zwischen Kommando (blau) und Event (orange) platziert werden. Beispielsweise hindert euch eine Programmregel daran, ein geschütztes Dokument zu speichern. Diese Regel wird auf einen lila Zettel geschrieben. Visualisierung:
Weitere Hinweise
- Ansichten variieren: Ansichten müssen nicht immer bildschirmfüllend sein. Auch ein Bereich einer Seite, wie z.B. ein Warenkorb oder eine Produktseite, kann eine Ansicht sein.
- Mehrere Elemente pro Person: Wir ordnen einer Person oft mehrere grüne (Ansichten), blaue (Kommandos) und orange (Events) Klebezettel zu, die wir untereinander anordnen. So entsteht eine detaillierte Skizze des Programms.
- Systeme als „Personen“: Manchmal modellieren wir ein System als „Person“, wenn es selbständig Kommandos ausführen kann. In diesem Fall benötigt das System keine Oberfläche, aber wir notieren es auf einem gelben Zettel und platzieren die entsprechenden Kommandos und Events daneben.
Zusammenfassung
Wir verzichten bewusst auf Phase 3. Durch die Phasen 1 und 2 ist das Programm bereits ausführlich beschrieben, und die Skizze der Oberfläche bietet ausreichende Details. Jeder Bereich kann nun seine Arbeitspakete ableiten. Mehr zur Detailplanung erfährst du in einem späteren Artikel.
Fallbeispiel: Eventstorming in Aktion
Mia, Stefan und Zou haben sich im letzten Artikel mit Brainstorming befasst und daraus alle Funktionen abgeleitet, die sie gerne umsetzen möchten. Heute möchten sie mit Eventstorming ihre Idee konkretisieren, um Arbeitspakete erstellen zu können.
Vorbereitung
Mia hat sich vorab ein geeignetes Whiteboard-Tool ausgesucht und verschiedenfarbige Klebezettel erstellt. Analog zum Brainstorming beginnen die drei, Events zu sammeln. Sie benennen Personen und beschreiben externe Systeme. Ein Ausschnitt daraus sieht wie folgt aus:
Gruppierung und Übersicht
Sie gruppieren die Events logisch, entdecken immer mehr und entwickeln eine erste Vorstellung ihres Videochats. Nach etwa einer Stunde haben sie alle relevanten Events zusammen, einige externe Systeme identifiziert und Personen beschrieben. Es entsteht ein riesiges Whiteboard – zum Glück sind die Klebezettel elektronisch leicht zu handhaben.
Den Dreien fällt auf, dass je nach Person das gleiche Event ausgeführt werden kann. Beispielsweise kann ein Gastnutzer eine Videochatanfrage annehmen, ebenso wie ein registrierter Nutzer. Die Events sind identisch und werden daher beiden Personen zugeordnet. Sie entscheiden sich, die Events zu duplizieren und den verschiedenen Personen zuzuordnen. Aus dem linearen Ablauf erstellen sie eine tabellarische Übersicht, indem sie die virtuellen Klebezettel duplizieren und den unterschiedlichen Personen zuweisen.
Phase 2: Vertiefung
Mia, Stefan und Zou fühlen sich bereit für Phase 2. Sie nehmen sich die erste Spalte vor und listen die Events untereinander auf. Links platzieren sie den Nutzer, rechts die Events. Dazwischen ist Platz für die grünen, blauen und lila Zettel. Für jedes Event überlegen sie nun, über welche Ansicht die Person welches Kommando ausführt, um das Event auszulösen.
Die Zeit vergeht wie im Flug, und schnell ist eine weitere Stunde vergangen. Mia schlägt eine kurze Pause vor. Obwohl es allen Spaß macht, ist das konzentrierte Arbeiten anstrengend. Nach 15 Minuten geht es weiter. Zou übernimmt die Skizzierung der Ansichten, da sie einen elektronischen Stift besitzt. Die Kontaktverwaltung nimmt bereits Gestalt an.
Abschluss
Für alle Events benötigen sie noch mehrere Stunden und einige Pausen. Am Ende haben sie drei Ansichten definiert: die Kontaktverwaltung, die Besprechungsplanung und die Besprechungsdurchführung. Zufrieden beenden sie das Eventstorming für heute. Da es bereits spät ist, entscheiden sie sich, den Abschluss des Workshops auf den kommenden Tag zu verlegen.
Wie du einen Workshop richtig abschließt und wie Mia und ihre Freunde damit umgehen, erfährst du im nächsten Artikel.
Hinweis: Dieser Artikel ist Teil unserer Serie über virtuelle Workshops und effektive Projektplanung. Entdecke weitere Beiträge zu Projektmanagement, agilem Arbeiten und Selbstorganisation auf unserem Blog.
Teile deine Erfahrungen oder stelle uns deine Fragen zum Thema virtuelles Eventstorming! Hinterlasse einen Kommentar oder diskutiere mit uns auf X oder LinkedIn.