Event Storming is often run at different 'altitudes' - commonly described as Big Picture, Process Modeling, and Design Level. What distinguishes these three variants, who attends each, and what artifact does each one produce?

## Zoom levels, not one fixed exercise Event Storming is not one fixed-scope exercise; it's a facilitation technique that gets applied at different zoom levels depending on what question the group is trying to answer, and conflating the levels is one of the most common ways teams get disappointing results from the technique. | Pass | Who is in the room | What it produces | |---|---|---| | Big Picture | a large, deliberately diverse group | a rough map of the whole territory | | Process Modeling | a smaller, more focused group | an actionable process description | | Design Level | a small group of developers plus one or two domain experts | detail enough to start implementing the corresponding code | ## Big Picture Big Picture Event Storming is the entry point for most teams and the one most people mean when they say "we did an Event Storming." The mechanism: a large, deliberately diverse group — fifteen to twenty-five people spanning product, engineering, support, operations, and any domain experts who touch the process — spends a few hours to a full day covering an entire business area or product end-to-end on one enormous timeline, staying intentionally shallow. The facilitator actively discourages the group from getting pulled into fine detail or technical solution-talk; the goal is coverage and shared awareness, not precision. The output is a rough map of the whole territory: - where the pain points are; - where the vocabulary gets murky between departments (a strong signal of a missing or misplaced bounded-context boundary); - which areas of the business are worth deeper investigation. ## Process Modeling Process Modeling Event Storming takes one process or bounded area identified as worth deeper investigation from a Big Picture session and re-runs the exercise with a smaller, more focused group over that single process, this time adding the fuller notation — **commands, actors, policies, read models** — to explain not just what happens but why and who's responsible. It stays in the problem/business space; it's still meant to be understandable by a domain expert without a technical background, and it does not yet commit to aggregate or persistence design. Its output is an actionable process description that a technical team can use as direct input to detailed design. ## Design Level Design Level Event Storming is the narrowest and deepest pass: a small group of developers plus one or two domain experts works through the process description with full technical precision, which means 1. drawing aggregate boundaries, 2. identifying invariants each aggregate must enforce, 3. pinning down exact command-handler and event-payload shapes. Its output is detailed enough that a developer can walk away and start implementing the corresponding code. ## Why they are separate passes The reason these levels exist as separate passes rather than one long session is a direct consequence of the trade-off between **breadth and depth**. - Getting twenty-five cross-departmental people in a room for the multiple hours a Design Level pass would require is both wasteful of their time (most have no useful input on aggregate invariants) and unrealistic to schedule. - Conversely, starting straight at Design Level with two developers skips the cross-functional discovery that catches misunderstandings before any commitment to technical design is made. Splitting into levels lets the right group size and the right amount of domain-expert time be spent at each stage of increasing commitment. ## The risk of conflating levels The main risk of conflating levels is **scope-creep in one direction or the other**. - A Big Picture session that drifts into aggregate-design arguments burns the limited attention of twenty-five people on a decision two developers and one domain expert could make far more efficiently later, and it alienates non-technical participants whose value was in surfacing business knowledge, not technical debate. - The opposite failure — skipping Big Picture and jumping straight to Design Level — risks locking in aggregate boundaries based on one team's local view of the process, without the cross-departmental check that might have revealed the boundary was in the wrong place. ## Putting the levels in sequence A worked scenario: a retailer running a Big Picture session across sales, warehouse, and customer support surfaces "Order Cancelled" as an event that means something subtly different to each department (sales means "refund issued", warehouse means "don't ship it", support means "close the ticket"). That ambiguity, caught cheaply in a three-hour Big Picture session, gets resolved with a follow-up Process Modeling session scoped just to order lifecycle, and only then does a Design Level session with two backend developers turn that into an Order aggregate with a clear cancellation invariant and separate downstream policies per department's actual need.