Software Design EventStorming is a collaborative modeling format for shaping software design and implementation around a specific business scenario. It turns a scenario into a shared visual flow, so people with different expertise can examine what must happen, where uncertainty lies, and how the solution should respond. Its value is not merely a finished board: the conversation creates shared understanding and exposes insights that individual design work can miss. section 2.3.2 section 11.3.1
Use it when the design question sits in the solution space of a stakeholder need, rather than across an entire enterprise or business line. Big Picture EventStorming addresses the broad domain; Process Modeling works between broad domain exploration and detailed software design. Software Design EventStorming can use the full EventStorming vocabulary and the interactions among its concepts, allowing a scenario to be discussed as a coherent flow rather than as disconnected requirements or technical components. section 2.3.2 section 2.3.2
Run a session as collaborative exploration rather than a handoff:
- Bring together the people who understand the scenario from different angles. The lightweight structure is intended to let participants contribute even without prior EventStorming knowledge. section 2.3.2
- Have participants model the scenario with domain events, initially allowing each person or group to express its own understanding. section 2.3.2
- Merge the separate views into a timeline. Use a pivotal domain event to decide what belongs inside the storyline and what happened before it. section 2.3.2
- Add and adapt concepts as needed. Colored sticky notes can carry meanings such as commands; extend the legend when a distinction helps the group reason about the scenario. section 2.1.3
- Mark assumptions, ambiguities, and hotspots instead of silently resolving them. Ask stakeholders what ambiguous words mean, and agree on terminology when one word hides multiple concepts or several words name one concept. section 2.1.3
- Translate discoveries into candidate design decisions, while facilitating disagreement so it remains functional rather than returning to unproductive conflict. section 9.3
Ticket-purchase scenario
A ticket-purchase flow gives a concrete starting point: visualize the events involved in purchasing a ticket, then combine the group’s separate event models into one timeline. A pivotal event can establish the boundary of the story, distinguishing events that belong to the purchase scenario from earlier context. The resulting discussion can reveal assumptions and design questions before implementation is settled. section 2.3.2 section 2.3.2
Treat the board as provisional. Discovery does not finish after one session: different participants, time for reflection, sharing the model beyond the initial group, and emerging conflicts or biases can all require another loop. Revisit the scenario and adapt the model as implementation context changes. The durable outcome is a better-informed group decision, not a supposedly final diagram. section 11.3.1
Figure 2.14 When to use each type of EventStorming. For modeling the problem space of an enterprise, domain, or business line, we use Big Picture. Designing the solution space of a stakeholder needs to be done with Software Design. For everything in between, we can use Process Modeling. On the left side, you see the different scopes of an organization where these types are typically used.
Compare EventStorming formats by organizational scope: use Software Design EventStorming for solution-space design around stakeholder needs, not enterprise-wide exploration. section 2.3.2
