The Workshop: Event Storming a Domain

For the story of Event Storming in action, see Event Storming: Building Shared Understanding — the Greenbox team running a smaller Process Level session on one flow. Big Picture is the same mechanics, scaled up to a whole domain.

About Event Storming

Event Storming is a sticky-note technique invented by Alberto Brandolini in 2013 for getting people with different knowledge of a process to build one shared mental model of it. Everyone stands in front of a long wall; each person grabs a pad of orange sticky notes and writes things that happened — in past tense, one per note — and sticks them on the wall. “Payment Submitted.” “Box Packed.” “Alert Fired.” “Deployment Rolled Back.” The wall becomes the shared surface. The sticky notes become the forcing function: you can’t hide behind vague hand-waving when you have to write a specific thing on a specific note and stick it where everyone can see.

Event Storming comes in three levels. This post covers Big Picture — the largest, most expensive level, used when the problem is “we can’t all agree on how this works” across multiple teams or departments. The other two:

• Process Level (default) — one specific process, 2–3 hours, focused team. Most teams, most of the time, want this. Don’t reach for Big Picture unless you genuinely need to look at a whole domain.
• Event Storming an Architecture — the code boundary around a process, 2–4 hours, architects and dev leads. Run it after Process Level has clarified the flow.

Big Picture is often the start of a ladder: use it to find the hotspots worth running Process Level sessions on, then use an Architecture session on the specific context you’re about to build.

Intent

Map a whole domain, product, or large subsystem as a chronological wall of events with everyone who knows a different part of it in the same room, so the organisation builds one shared picture and identifies the hotspots worth zooming into.

Also Known As

Brandolini calls this Big Picture EventStorming, and it’s the level the technique is most famous for — the one with the long wall of orange sticky notes, the crowd, and the explicit walkthrough. Sometimes shortened to “Big Picture” when the context makes the technique clear. Not to be confused with executive vision workshops, strategy offsites, or the kind of roadmap exercise that produces a single diagram — Big Picture is deliberately messy and deliberately chronological.

Motivation

Several teams are working on the same product area. Each team knows their own slice. Nobody has seen the whole area on one wall — and it shows. Cross-team decisions take weeks. Every initiative runs into the same invisible mismatches. When something breaks end-to-end, nobody can reconstruct what happened without six separate meetings.

A SaaS company’s billing platform spans four teams: payments (Stripe integration, card handling), invoicing (invoice generation, tax, dunning), the customer portal (where subscribers see their bills and payment methods), and the accounting integration (feeding the finance system). Each team is competent in its own slice. But when marketing wants to launch a new pricing tier, or customer support needs to explain why a refund took three days to appear, or an engineer needs to change how prorated charges work — every one of those changes touches all four teams, and nobody has a single picture that shows the whole billing platform on one wall.

Or: a fintech’s customer onboarding flow — from marketing site through signup, identity verification, risk scoring, approval, and first funded transaction. Five or six teams touch it. Every one of them knows their step cold. Nobody can walk the whole thing end-to-end without stopping three times to ask someone else what happens next.

Or: a production incident that crossed six services and took four hours to resolve. The timeline lives in Slack, git history, and people’s heads. A Big Picture session with those six teams reconstructs what actually happened — and the reconstruction surfaces the handoffs nobody had previously made explicit.

Big Picture is the workshop you reach for when the problem isn’t a flow — it’s a coherent product area spanning several teams that need to see it on one wall.

What’s the right size?

This is the question Big Picture gets wrong most often. “Map the whole business” is not the right framing. Neither is “model one flow.” The sweet spot sits in between, and being too loose about which one you’re in is the most common reason sessions disappoint.

Too big. Don’t try to Big-Picture an entire enterprise. You can’t Big-Picture a mining conglomerate that runs open-pit mines, rail networks, shipping ports, and a hydrogen trading business — that’s not a domain, it’s a collection of separate businesses each of which would need its own Big Picture. You can’t Big-Picture “all of Amazon” or “all of our bank.” If you find yourself asking “whose slice do we even start with?”, the scope is too big. Break it into several coherent areas and run a session on one.

Too small. Don’t use Big Picture for a single process, a single deployment pipeline, a single flow one team owns. Those are Event Storming a Process sessions — faster, cheaper, and better-shaped. If one team could hold the whole thing in their heads during a normal sprint planning, you don’t need Big Picture.

The sweet spot. Something you can describe in a single phrase — “the billing platform”, “customer onboarding end-to-end”, “the subscription business” — that:

• Spans 3–6 teams in a way that makes cross-team meetings regularly frustrating
• Is coherent enough to fit on one wall over a day or two
• Has enough texture to have hotspots — places where different teams disagree, points where handoffs confuse, parts where the reality has drifted from the documentation
• Is owned by nobody as a whole — every team owns a slice, no single person holds the full picture

Concrete examples that fit well:

• A SaaS company’s billing platform (payments, invoicing, customer portal, accounting integration)
• An e-commerce business’s cart-to-delivery flow (cart, checkout, payments, fulfilment, logistics, comms)
• A fintech’s customer onboarding (marketing, signup, identity verification, risk, compliance, first transaction)
• A health app’s patient journey from first visit through diagnosis through ongoing care
• A cross-team post-incident review where the incident crossed enough systems that a conversation can’t hold the shape
• A new major feature area that will cross 4–5 existing teams and needs one picture before anyone commits to a scope

If you can’t find a phrase that names your scope cleanly, you probably don’t have a Big Picture problem — you have either a Process Level problem (one flow) or a strategy problem (which product area matters), and Event Storming isn’t the tool for the second.

Applicability

Use when:

• A major initiative is starting and the whole organisation needs one picture before it begins
• A new team is onboarding into a complex product and needs to learn the whole shape, not just their slice
• The organisation has drifted into multiple mental models across departments and decisions are stalling because of it
• You’re planning an M&A integration and the two sides need to see each other’s domains on one wall
• You want to find the right place to run a Process Level session and you don’t yet know which flow is the most valuable to zoom into

Don’t use when:

• You already have a specific flow you need to model — use Process Level instead
• You’re ready to design code — use Event Storming an Architecture instead
• You can’t get the right people in the room for a whole day — half-doing a Big Picture is worse than not running one
• Leadership will sit in the room and correct people — you’ll get political theatre, not discovery
• The scope is a single team, a single product, or a single well-understood flow — it’s too much machine for the job

Participants

Facilitator. Ideally two facilitators for anything over ten people — one watching the wall, one watching the room. Big Picture is much harder to run than Process Level because the group is bigger, the conversations are noisier, and the failure modes are more political. Don’t run your first Big Picture alone.

Domain experts from every part of the domain. Not a crowd from one department — one or two people from each. For a SaaS platform that means product, engineering, support, sales, operations, finance. For a bank that means front office, back office, risk, compliance, IT. The rule is: if a slice of the domain isn’t in the room, it’ll be missing from the wall.

Developers and architects. Not to design, not to argue about code — to listen, to write their own events, and to discover where the business model and the code model have drifted apart.

Operations, support, and the frontline. The people who actually run the system. Their events are the ones that surprise everyone else, because they’re dealing with the reality leadership doesn’t see. Don’t tuck them in as afterthoughts; they’re often the most valuable voices in the room.

Sometimes leadership — with care. A sponsor who can answer “why are we doing this” and then get out of the way is useful. A leader who stays in the room and corrects people kills the session. Brief them in advance. If they can’t hold that, run without them.

Group size: 5–20. Brandolini’s guidance is “everyone who matters” — the whole point is that Big Picture specifically wants more voices than Process Level because you’re looking for the cross-team mismatches that only surface when the right people are all present. Below 5 and you’re really running a Process Level session with pretensions. Above 20 and the conversation fragments and some voices stop contributing.

Who to leave out:

• Pure observers and consultants who aren’t part of the domain. Anyone “just listening” absorbs airtime without contributing. Either in or out.
• End customers and users. People self-censor around the people they serve. Bring their voices in through interviews, not in person.
• Leadership who can’t hold the discipline. If a VP corrects every event they disagree with, the frontline will stop writing. Brief them; if they can’t hold it, run without them.
• Anyone attending only because they’d be offended to be left out. Political attendance is negative-value attendance.

Structure

Phase	Duration	Materials	Key question
Arrivals, intro, ground rules	30 min	—	“What are we doing and why?”
Chaotic exploration	60–120 min	Orange notes	“What happens in this domain?”
Timeline construction	60–90 min	Orange notes, arrows	“What order? What connects to what?”
Break	30–60 min	—	—
Explicit walkthrough	60–180 min	A walker, a listener	“Does this match what you know?”
Problems and opportunities	60–90 min	Pink notes, systems, people	“Where does this hurt?”
Voting / prioritisation	30 min	Dot voting	“Which hotspots matter most?”
Wrap-up and owners	30 min	—	“Who owns what next?”
Buffer	30–60 min	—	—
Total	A full day minimum. Often two or three.

The five working phases alone run from about 4.5 hours (simple domain, small group, low hotspot count) to 8.5 hours (complex domain, larger group, high disagreement). Add arrivals, breaks, wrap-up, and the buffer for conversations that run long, and a Big Picture session is 6.5 to 11.5 hours of elapsed time — a full day minimum, and often two or three when the scope is large. It isn’t a workshop you cram into an afternoon.

A note on note colours. Big Picture uses fewer colours than Process Level, deliberately. You’re not looking for precision — you’re looking for shape. Orange events are the backbone. Pink notes mark hotspots, confusion, and pain. Yellow notes mark systems and people (loosely, not precisely). That’s it. No blue commands, no purple policies, no green read models — those belong at Process Level, where you’re modelling a flow you’ve already decided matters.

The discipline is: fewer colours, bigger wall, more voices. If you find yourself reaching for commands and policies, you’re on the wrong level.

Collaborations

The session alternates between silent writing (lots of it), timeline construction (noisy and messy), the explicit walkthrough (one voice, many listeners), and hotspot conversations (small clusters). The rhythm is deliberately messier than Process Level because the group is bigger and the domain is larger.

The key mechanic is the explicit walkthrough: one or two people walk the timeline end to end, out loud, while everyone else watches and interrupts. This is the heart of Big Picture. It’s where the mismatches surface — not when people are writing their own events, but when they hear someone else narrate the whole flow and something catches them in the chest because it doesn’t match what they thought they knew.

Write first, walk the timeline second, challenge the walker third. Anyone in the room is allowed to interrupt the walker at any point. Interruptions are the output.

Before the Session — Scope with the Sponsor

The single most common way Big Picture sessions go wrong is that the scope was agreed in a calendar invite and not in a conversation with the person who owns the output. Meet the sponsor — the leader who asked for the session — the week before, and walk through four things.

1. Scope in one phrase. “The billing platform end-to-end.” “Customer onboarding from lead to first successful transaction.” “The post-incident review for the February outage.” If you can’t name the scope in one short phrase that the sponsor and you both agree on, the session will drift. A fuzzy scope is the thing that turns 10 hours into 4 hours of discovery and 6 hours of rework.
2. Who to invite. Who are the 5–20 people who hold the full picture together? Which teams will argue if they’re not represented? Which ones are redundant? Confirm each name with the sponsor. If a key person can’t come, either reschedule or scope around them — “this session can’t cover compliance without compliance in the room, so compliance is out of scope today.”
3. The sponsor’s role in the room. Ideally: the sponsor opens the session (“why we’re here, what I need from you, what I’ll do with the output”), then physically leaves and comes back only for the wrap-up. They are not a participant. If the sponsor can’t hold that discipline — if they’ll correct every event they disagree with, or hover and visibly react — the session will become political theatre. Be explicit with them: “Your job is to introduce and to close. In the middle, you need to be somewhere else.” If they resist, reschedule.
4. The question the session must answer. Not “do a Big Picture” — that’s the method, not the outcome. The outcome is usually: “prioritised list of 3–5 cross-team hotspots worth a Process Level follow-up,” or “shared picture everyone can point at when they disagree later,” or “which team should own what when we do the next major release.” Agree with the sponsor what the output is for, and make sure the session produces it.

Without this pre-work, a Big Picture is a coin flip. With it, you’ve already done half the facilitation before the first sticky goes up.

Facilitator Playbook

Before the phases, here’s a running example the rest of this section will reference — the same subscription service the Process Level and Architecture posts use, but zoomed all the way out. Process Level mapped the subscriber lifecycle inside the product — from sign-up through to support tickets, as a sixteen-triplet wall. Architecture zoomed further in, on one specific event (Plan Upgraded), to draw aggregate boundaries. Big Picture stretches the Process Level wall in every direction so the teams around the subscriber lifecycle can see their slice too.

Imagine the sponsor has booked a full day with people from across the business: someone from marketing, someone from product, a billing engineer, a customer-success manager, a support lead, a finance analyst, and an SRE. The scope: “the whole subscription business — how a stranger becomes a paying customer, how they grow, how they churn, and how we win them back.”

When you zoom out from the Process Level wall, new things appear upstream, downstream, and to the sides:

• Upstream (before registration): ad campaigns, lead capture, trial signups, trial-to-paid conversion. Marketing owns most of it, and half these events never appeared on the Process Level wall because they happen before the subscriber exists in the product database.
• Downstream (after cancellation): exit surveys, win-back offers, returning customers, accounting write-offs, churned-MRR reporting. Finance and marketing own most of these, and most of the engineering team has never thought about any of them.
• Sideways (adjacent to the lifecycle): tax calculation, PCI compliance, accounting integration, fraud review, regulatory reporting. Nobody on a single team holds the full shape — and that’s exactly the hotspot Big Picture exists to find.

Here’s the shape of the wall at the end of the day — drastically simplified for legibility, but showing the six phases, a sample of events in each, the two teams most often in contact with each phase, and the pink hotspots that surface during the walkthrough:

The moment this wall earns its cost is during the explicit walkthrough, when the customer-success manager interrupts the walker to say “wait — our churn risk model runs on day 25 of the billing cycle, but the retention offer needs marketing approval and marketing meets on Tuesdays, so half the save offers land after the customer has already cancelled.” Nobody on a single team could have seen that. Four people in a corridor would have argued about it for months. On the wall, with all the phases visible at once, it takes ten seconds to spot and a pink note to capture.

That’s the thing Big Picture is for: the mismatches that only become visible when the whole wall is on view.

Phase 1 — Chaotic exploration (60–120 min)

This is Process Level’s chaotic exploration, scaled up. Much bigger wall, many more voices, much more silence at the start while people absorb the scale.

Set the safety out loud:

“Every note is valid. Duplicates are fine. Things that might be wrong are fine. If you’re not sure what to write, write it anyway — that’s exactly the kind of note that makes this session work.”

Set the granularity with examples from across the domain, not just one slice:

“These are domain events — things that happened, past tense. ‘Subscription Activated.’ ‘Invoice Raised.’ ‘Complaint Filed.’ ‘Integration Deployed.’ ‘Account Suspended.’ Write at the level where a person in the business would say it out loud.”

Name the most junior or most frontline person in the room and have them go first. You’re setting the pattern: this isn’t an executive meeting, it’s a working session, and the least senior person writes first.

Then give the one instruction:

“Write silently. Get everything you can think of about how this domain works onto orange notes and onto the wall. No order. No worrying about duplicates. No talking. Sixty minutes on the clock, then we stop.”

For a genuinely large domain, run this in two blocks: 60 minutes, short pause to breathe, another 60 minutes. By the end you should have 150–400 orange notes. If you have fewer than 100, either the scope was wrong, the people were wrong, or the room hasn’t yet believed you that writing is the job.

What to watch for:

• Talking instead of writing. “Get it on a note. We’ll talk at the timeline.”
• Whole departments not writing. If everyone from support has three notes between them and sales has forty, something is wrong. Move the facilitator over. Make eye contact. Invite specific events.
• Someone filling the wall while their team watches. Usually sorts itself in the next phase, but note it.
• Executive events only. “Strategy Agreed.” “Board Met.” If the wall is all leadership verbs, the frontline isn’t contributing yet.
• People writing wishes instead of events. “That sounds like what we want to happen. What actually happens?”

Phase 2 — Timeline construction (60–90 min)

Everyone talks. The job is to arrange the hundreds of orange notes left-to-right in chronological order. It will be messy, it will feel impossible at first, and that’s expected.

Open with:

“Put these in order. Don’t worry about perfection — the goal is rough chronology. If two things happen in parallel, put them in parallel. If you disagree about where something goes, put a pink note on it and move on.”

Walk the room. Prompt clusters to form around parts of the domain (“everything before signup over here, everything about the paying customer in the middle, everything about churn on the right”). Accept that the timeline will have several overlapping tracks — a big domain doesn’t flatten into one line.

About 30 minutes in, pause and find the pivotal events. This is the single most productive move in timeline construction, and first-time facilitators almost always skip it. A pivotal event is one of the 4–8 key state changes where the domain fundamentally shifts — “the trial ended and they became a paying customer”, “the claim was approved”, “the patient was admitted”, “the customer cancelled”. Everything else hangs off them.

Stop timeline construction for five minutes and ask the room:

“What are the 4–8 most important events on this wall? The moments where the state of the customer, the product, or the business fundamentally changes? Call them out.”

Mark each pivotal event with a tall red dashed line down the wall at that point, or a large dashed box around it. Once the pivotals are visible, the rest of the timeline organises itself into the phases between them — “before trial-to-paid”, “after trial-to-paid”, “before exit”, “after exit”. The phase labels on the Big Picture wall aren’t something you plan up front; they emerge from the pivotal events. Teams that skip this step spend the next thirty minutes arguing about whether “Card Expired” goes before or after “Renewal Notice Sent”; teams that do it first stop caring, because the pivot point is “renewal approaches” and both events belong to the same phase.

What to watch for:

• One department dominating timeline construction. Pair people from different departments and give them sections.
• No pink notes at all. Disagreements are hidden, not absent. Prompt: “Is anything on this wall surprising you?”
• Rabbit holes into policy debates. “Great policy conversation — park it. We’re looking for rough chronology.”
• People trying to make it tidy too early. “It’s supposed to be messy. Tidy comes in Process Level, not here.”
• Duplicates proliferating. Leave ambiguous ones — if two notes might be the same event, that’s a pink note, not a merge.
• No pivotal events getting called out. The team may be too deep in the weeds. Name two you think are obvious (“trial → paid”, “exit”) and ask which other ones they’d add. Then let them disagree.

Phase 2b — The reverse narrative (20–30 min)

Before the explicit walkthrough, walk the wall backwards once. This is a Brandolini move that sounds strange and is the single most effective way to find missing events.

Start at the rightmost event and ask: “What had to be true for this event to happen? What had to happen just before it?” Work right to left. Every gap the room can’t answer — “we don’t know what happens before this one” — goes on a pink note and, usually, a new orange sticky appears a moment later to fill the gap.

“Going forwards, we tell a story we already believe. Going backwards, we discover the bits we’ve been handwaving. Every ‘we don’t know’ is a pink note. Every ‘oh wait, it must be…’ is a new orange sticky.”

Expect to find 20–40 new events in a big domain on the reverse pass — most of them on the left side of the wall, where the early steps got skipped because nobody in the room owns them. This is where the cross-team gaps become undeniable: three teams each discover they don’t know how something actually starts, and the answer almost always involves a team that isn’t in the room. Those are follow-up Process Level candidates.

What to watch for:

• The walker rushing forwards instead of backwards. Gently redirect: “No, start at the end. What had to be true for this last event to be possible?”
• “We already know all that” resistance. Name it: “We’ll find out in the next five minutes. If we don’t discover a missing event, I’ll apologise and we’ll move on.” Usually you’ll find one inside two minutes.
• People trying to fix the gaps in-session. “Capture it, don’t solve it. We’re mapping what’s true, not redesigning it.”

Phase 3 — The explicit walkthrough (60–180 min)

This is what Big Picture is for. Everything before was preparation. Now one person — ideally someone who thinks they know the whole flow — walks the wall end to end, out loud, narrating each event in order, as if they were explaining it to a newcomer.

Frame it:

“One of us is going to walk this wall from start to finish, out loud. Their job is to narrate what happens at each event. Everyone else’s job is to listen and interrupt when something doesn’t match what you know. Interruptions are the point of this exercise. Don’t hold them back — this is the one part of the session where talking is the job.”

Pick the walker carefully. Not the most senior person. Not someone who’ll perform. Someone who knows a lot but not everything, who’ll narrate what they think is happening and be genuinely surprised when someone corrects them.

The walker moves slowly. Ten seconds per event, minimum. For a big wall with 300 events that’s an hour just to walk it, and that’s without interruptions. Budget accordingly.

Every interruption is precious. Write the disagreement on a pink note and stick it on the event that triggered it. Don’t try to resolve the disagreements in the walkthrough — capture them and move on. You can come back.

For a very large wall, split the walkthrough: two or three walkers take different sections, each with their own listeners, then converge.

What to watch for:

• The walker turning it into a lecture. Ten seconds per event, not a minute. “Keep it moving — the interruptions are the output.”
• Nobody interrupting. Either the walker is genuinely correct (possible, rare) or the room has stopped listening. Pause, stretch, and ask one specific person directly — by name and by the slice they own: “From where you sit in support, does this match what you hear on the phones?”
• Interruptions becoming arguments. “Pink note it, we’ll come back. Keep walking.”
• The walker skipping sections they don’t know. “Good — stop there. Who knows what happens next?” Let someone else take over for that stretch.
• The room losing energy halfway through. A 3-hour walkthrough is genuinely hard. Break it into 45-minute segments with stretches between.

This phase is the one people remember for years. Protect it.

Phase 4 — Problems and opportunities (60–90 min)

Now add the pink notes properly. You already have some from the timeline and the walkthrough; add more deliberately. Also add yellow notes for systems (the ones showing up across the wall) and for people (roles that keep reappearing).

Prompt:

“Where does this hurt? Where is there friction? Where do people work around the system? Where is information lost? Where does a decision get made with the wrong context? Every pain point is a pink note.”

Don’t try to solve anything yet — just surface it. The wall should look dense with pink by the end.

What to watch for:

• Pink notes stuck only in one department’s area. Either that department is the only one with problems (unlikely) or the others have stopped contributing. Prompt explicitly.
• Pinks that are really feature requests. “What’s the event that’s currently missing or painful?” Reframe as a domain problem, not a solution.
• Executive pinks dominating. “Strategy unclear.” Useful, but balance with frontline pinks: “Customer can’t see the current status of their order.”
• Repeating pinks in different areas. That’s a theme. Name it out loud.

Phase 5 — Voting and prioritisation (30 min)

There will be too many pinks. That’s normal. Dot voting turns the wall into a prioritised list.

Give everyone a fixed number of dots (usually 5–7) and let them place dots on the pinks that matter most. Then count. The clusters with the most dots are the candidates for follow-up Process Level sessions.

Frame it:

“We’re not fixing anything in this room. We’re picking the top 3 to 5 places to dig into next — the places where a Process Level session will be most valuable. Put your dots on the pink notes where you’d most want to zoom in.”

What to watch for:

• Leadership dots dominating. If leadership has voted and frontline hasn’t, the result is the leadership’s priorities with a veneer. Ask frontline to vote first, or do the votes anonymously.
• Dots concentrating on one department. That department’s pinks may genuinely be the worst, or the voting has been political. Worth a one-minute conversation about the distribution.
• Pinks with zero dots. Don’t throw them away — they’re still captured. Photograph the wall so they survive.

Steering When It Goes Sideways

Named failure modes. Each has a symptom, a recovery move, and a threshold where you stop rather than limp through.

Nobody will commit to the whole day. Half the room drifts in and out. The session gets compressed.   Recovery: Stop and reset. Rebook with people who will commit. A compressed Big Picture produces a fake picture.   Stop if: Two hours in and half the room is still on and off their laptops. You’re not running a workshop, you’re running a meeting with sticky notes. Stop, apologise, reschedule.

Too many cooks. Twenty people in the room and some aren’t contributing.   Recovery: Break into sub-groups during chaotic exploration — each sub-group takes a zone of the wall. Reconverge for the walkthrough.   Stop if: The split doesn’t help and several people are clearly disengaged. Invite them to leave; thank them; continue with the ones committed to contribute.

Political theatre. Leadership is in the room, corrects every event they disagree with, and the frontline has stopped writing.   Recovery: Name it, carefully. “We need the frontline view right now. Let’s hear from support and ops first, then we’ll come back to strategy.” If the senior can’t hold it, ask them to step out for a “call” (brief them in advance that this might happen).   Stop if: The dynamic doesn’t shift and the frontline is visibly withdrawing. Photograph the wall, thank everyone, reschedule without the leader.

Hotspot overwhelm. Eighty pink notes and nobody knows what to do with them.   Recovery: Cluster them into 5–10 themes before voting. Don’t vote on individual pinks — vote on themes.   Stop if: The themes don’t cohere either. Capture what you have, photograph thoroughly, and make the follow-up “sort through this offline” rather than “decide now.”

The sprawling scope. The wall keeps growing and nobody can see the whole thing anymore.   Recovery: Pick the part that has the most energy and declare the rest “for another session.” Big Picture doesn’t have to mean “everything in one session.”   Stop if: The room genuinely needed the whole thing and you’ve only captured a fragment. Plan a follow-up day; don’t pretend a partial wall is the whole picture.

The wall of one department’s events. 90% of the wall comes from engineering, or 90% from sales.   Recovery: Pause writing. Ask each under-represented department to spend 20 minutes adding events from their slice, with a facilitator present.   Stop if: A department simply has nothing to add. Either they shouldn’t be in the room (the scope was wrong) or there’s a deeper problem worth surfacing directly: why doesn’t their slice feel domain-shaped?

Leadership sidebar. Two or three senior people cluster together and start having their own meeting beside the wall.   Recovery: Interrupt it, politely, out loud. “There’s a sidebar forming — can we bring that into the room?” Most sidebars collapse when named.   Stop if: The sidebar absorbs the session. Two rooms aren’t a workshop; one of them is the real decision-making and the other is theatre.

Consequences

Benefits

• Cross-team alignment on how the domain actually works, end-to-end
• A prioritised list of hotspots — the places where a Process Level session will be most valuable
• Mismatches between departmental mental models surfaced in public, before they cause cross-team damage
• Shared vocabulary — the beginning of what DDD calls a ubiquitous language — that starts to stabilise across business and IT
• A physical artefact (the wall, the photographs) that outlives the session by months

Costs

• 40–160 person-hours for a one-day to three-day session
• Logistical difficulty of getting 5–20 senior domain experts for the whole time
• Political risk when hierarchies flatten and frontline events contradict leadership’s story
• The most expensive of the three Event Storming levels by a wide margin — and the easiest to do badly
• Reputational cost if a first Big Picture flops; sponsors are harder to find the second time

Failure modes

• The session produces one department’s picture of the domain
• Leadership dominates and the frontline stops contributing
• The scope was too abstract and the wall fragments into disconnected regions
• The walkthrough never happens (ran out of time) and the value evaporates
• The hotspots are captured but nobody ever runs the follow-up Process Level sessions

Stop-the-session signals

• Two hours in and half the room is still checking laptops or stepping out for “urgent” calls
• The wall is sparse and nobody can figure out why
• The room has divided into leadership and everyone else, and pairing hasn’t shifted it
• The walkthrough has become a lecture nobody is interrupting

Ending early is not failure. A compressed, politicised, or low-energy Big Picture produces a false picture that will mislead decisions for months. Better to reschedule.

Worked Example

The subscription-service wall in the Facilitator Playbook above is the Big Picture version of the same domain the Process Level and Architecture posts work on. The zoom chain:

• Big Picture (above) — the whole subscription business across six phases, sixty-plus events on the wall, a handful of pink hotspots, one walkthrough moment where the churn-risk/marketing-approval mismatch lands in the room.
• Process Level — zooms into phases 2 through 6 of that wall (onboarding through exit and support), keeps the core events, adds commands and actors, and ends with a precise sixteen-triplet wall that’s ready to design on. Phase 1 (Acquisition) drops out because it’s not what the product team is building.
• Architecture — zooms further into a single event from the Process Level wall, Plan Upgraded, and asks where the code boundaries go. That one event becomes three subscriber aggregates (Billing, Access, Email) each with its own policy, read model, commands, and emitted events.

Each zoom drops detail from the levels above and adds detail the levels above couldn’t see. The wall you’d photograph at the end of each session gets progressively smaller and progressively richer.

For the Greenbox team’s version of the same technique applied to a physical-goods subscription (a produce-box business), see Event Storming: Building Shared Understanding — they ran a Process Level session rather than Big Picture because their team was small enough that one flow held the whole picture, but the mechanics and the colour palette are the same.

Outputs & Follow-up

Facilitator’s close-out (same day, 24 hours)

• Panoramic, high-resolution photographs of the wall. Multiple shots, overlapping, so the wall can be reassembled digitally. For a very long wall, take one photograph per metre.
• Transcribed event list, system list, and hotspot list in a shared document, organised by rough zones.
• A short summary message to all participants: “here’s what we found, here’s the prioritised hotspots, here’s what happens next.” Send it within 24 hours while the energy is still fresh.

The product owner’s week — or the sponsor’s week

Big Picture is often sponsored by a leader rather than a product owner — a CTO, a head of product, a programme director. The follow-up is their job and it’s substantial.

• Turn the top hotspots into a schedule of Process Level sessions. Each dot-voted cluster is a candidate. Prioritise by impact and by who’s available. Book them within two weeks — momentum dies fast after Big Picture.
• Name the vocabulary that emerged. The words that kept appearing on the wall are the start of the organisation’s shared language. Pin them down. Circulate a glossary.
• Walk the wall with anyone who couldn’t attend. Especially peers of the attendees — their reaction tells you whether the picture is landing beyond the room.
• Use the hotspots in planning conversations. The wall is the most credible input any current-state discussion can have. Don’t let it become a photograph on a shelf.
• Write the stakeholder one-pager. Lead with the three or four surprises from the walkthrough — the moments where someone’s mental model broke. Those are the memorable artefacts of the day.

Ongoing

• Keep the wall physically visible for as long as you can, or keep large printed copies on the office wall. A Big Picture map is more credible in situ than in Confluence.
• Revisit the wall six months later with the same group. Note what has moved, what has been built, what was right, what was wrong. Big Picture is a snapshot; a re-walk is how you see the change.
• Don’t try to keep the wall “current.” It’s a snapshot of a moment, not a live document. Run another Big Picture when the snapshot is stale enough to mislead.

Related Patterns

• Process Level Event Storming — the natural follow-up. Big Picture finds the hotspots; Process Level zooms into each one and models it precisely.
• Event Storming an Architecture — further downstream. Once Process Level has clarified a specific flow, an Architecture session turns it into bounded contexts and component APIs.
• Impact Mapping (publishes later this week) — Big Picture describes how the domain works now; Impact Mapping describes what you want to change and why. Run them together on major initiatives: Big Picture to see the ground, Impact Mapping to pick where to push.
• Wardley Mapping (publishes later) — where Big Picture is chronological, Wardley is evolutionary. They answer different questions and complement each other well at the start of a major programme.
• Example Mapping (publishes later this week) — the zoomed-in Process Level sessions that follow Big Picture often feed Example Mapping for the rules and examples the team needs to build against.
• Retrospectives — a cross-team post-incident review at the scale of “this incident crossed six teams and nobody can explain it” is essentially a Big Picture session with an incident-shaped scope.