The Workshop
Facilitator playbooks for the sessions that keep worth running again: what each workshop is for, who to invite, how to run it, and what goes wrong. Each published playbook comes with a printable one-page summary for the wall and a full guide for your tablet.
The widest zoom, and Brandolini's own entry point to Event Storming. Stand a whole business (or a whole product) in front of one wall with everyone who touches it. The output isn't a design or a plan; it's one picture that every department recognises, and a shortlist of the places worth digging into next.
The default Event Storming session and the one you'll run most often. One process, one wall, everyone who touches it in the room, three hours. You leave with a precise shared model of the flow and a short list of the questions it raised. Where Big Picture looks for shape across a whole domain, Process Level looks for precision within one flow.
A pattern for breaking a user story into rules and concrete examples in twenty-five minutes, so the team knows whether it's ready to build before the sprint starts. Facilitator's playbook, failure modes, and what to do with the cards afterwards.
A pattern for turning a refined backlog into a sprint the team believes in: a goal, a set of stories, task breakdown, and an explicit commitment, in one focused session.
A pattern for tracing a business goal through the people whose behaviour has to change, through the changes themselves, to the things you might build — so the team can tell the difference between work that moves the number and work that just feels productive.
A pattern for laying out the whole user experience as a left-to-right narrative and then slicing it into releases, so the team can see both the shape of the thing they're building and the thinnest honest version they can ship first.
A half-day pattern for finding out what your customers actually hired your product to do. Switch interviews, the four forces, shaping the material into job statements, and what to do when the room wants to list features instead.
A pattern for surfacing the beliefs hiding underneath a plan, plotting them on an evidence/impact grid, and deciding which ones to test before you commit. Facilitator's playbook, failure modes, and what to do with the grid afterwards.
A pattern for laying out how a business creates, delivers, and captures value on a single page of nine boxes, filled in customer-first order, so the team can see whether the whole thing actually holds together.
A 60-to-90 minute pattern for picking the next order of work when the backlog has outgrown the room’s memory. MoSCoW, RICE, Cost of Delay, value-vs-effort — not as rival religions, but as lenses chosen to fit the constraint. Silent scoring, reveal, argue the fringes, land the order.
Event Storming at its most precise. Take a Process Level wall and a team of developers; leave with aggregates, bounded contexts, and a design the room actually believes in. The session that turns 'we understand the flow' into 'we know where the code goes'.
A simple set of nested diagrams (Context, Container, Component, Code) that turns a wall of sticky notes and tribal knowledge into an architecture artefact that survives outside the room.
A pattern for turning 'we should be doing something with AI' into a short portfolio of bets worth piloting, and an honest list of the ideas that aren't AI problems at all. Diverge across the business, score on value and feasibility and data and cost-of-being-wrong, pin each survivor to an autonomy level, and walk out with two or three pilots instead of a hackathon backlog.
Half a day with a clarified Event Storming wall, a whiteboard, and the correct people — to land on aggregates, bounded contexts, and a context map the team will actually re-read. Where Event Storming an Architecture produces the first cut of boundaries, this is the session that sharpens them.
A pattern for extracting a tangled business rule from a domain expert's head and laying it out as a conditions-and-outcomes grid, so the combinations nobody had thought of become visible before they become bugs.
A pattern for creating a structured, safe space to inspect how the team is working and decide one or two things to change, so that continuous improvement stops being a poster on the wall and starts being a thing that actually happens.
A pattern for laying the components of a value chain (the sequence of capabilities a user needs, top visible to the user, bottom foundational) against an evolution axis, so that build-buy-borrow arguments stop being about taste and start being about where each component actually sits.
A review session run against a projected, generated event-storm wall. The facilitator scrolls the whole domain top to bottom, runs mechanical audits that turn model defects into questions the room answers, and closes by counting the open-question cards down live. Ninety minutes, and the model is more honest at the end than at the start.
On the way
Not sure which session fits the problem in front of you? The technique-to-story map lives on the techniques page.