Pivotal Events

In EventStorming, Pivotal Events act as splitters between distinct phases of the business flow.

They are instrumental in building a structure for the many narratives of a business flow, and provide information that may be useful later, when decomposing the system into possible Bounded Contexts.

Detecting Pivotal Events

During the enforce the timeline step of a Big Picture EventStorming, we might ask the audience for common events that look like good splitters between different phases. Events with a clear distinction between before and after.

We might select key moments of the overarching business transaction, such as Contract Signed, Payment Received, Item Delivered, etc.

The number of duplicate sticky notes might also provide insights. The narratives of different participants tend to converge on the same events.
The precise wording may differ (and be interesting to investigate), but a cluster with compatible interpretations likely signals an event at a responsibility boundary.

Speed beats precision

In a typical Big Picture EventStorming, the model progressively emerges from discussion in an iterative progression from chaotic to structured. When we first scout our first pivotal events, we might still be somewhere in the fog, looking for the first seeds of a structure.

Therefore, we typically spend little time in the detection phase. There isn’t enough information yet to strive for perfection. We need plausibility and a balanced distribution of the areas between the Pivotal Event.

An event at the very beginning or the very end is not a good candidate for a Pivotal Event; a splitter needs to be somewhere in the middle.

Marking Pivotal Events

During in-person workshops, we usually highlight Pivotal Events with a paper tape. This allows for replacing and rearranging if new insights emerge during the discussion.

Note: In online workshops, we use a larger size and bold font to differentiate pivotal events from the standard ones. We often use different colours during the initial exploration, using orange to signal that an event has been discussed/accepted.

Whatever the chosen notation, it should be easily reversible. Pivotal Events aren’t precise yet.

Once the first Pivotal Events are highlighted, we try to rearrange the remaining events to be coherent with the new dominant narrative.

This rearrangement process often leads to more refinements in the flow structure, such as more splitters and horizontal swimlanes.

Refining Pivotal Events

The original detection phase is fast, meaning that we are trading precision for plausibility. We need to establish a workable structure quickly, and the initial Pivotal Events candidates may require a few revisions before they are agreed.

You may find events describing the same concept at different levels of precision, or displaying nuances which may be worthy of a deeper discussion.

Don’t expect to finish the workshop with the same Pivotal Events you selected in the kick-off stages.

Pivotal and Domain Events

Pivotal Events live only inside an EventStorming Workshop. They are a tool to highlight the special role of certain events during a Collaborative Modelling experience. We can leverage participation to improve the wording, challenge the semantics, or count the number of downstream listeners (systems and stakeholders) who will be interested in a specific Pivotal Event.

But a discovery workshop is a great place to gather information, but not to do precise design; this is the homework for the next day.

If our implementation adopts an Event-Driven Architecture, then our Pivotal Events are the best candidates to become Public Events, part of an Event-Driven Published Language (see Context Mapping) that connects the different Bounded Contexts within a system.

If some of your Bounded Contexts implement variations of Event Sourcing, you should pay special attention to considering the different interpretations of public events between producers and consumers.

For example, two events like Product Page Published and Product put on sale may apparently refer to the same thing. But this may be the current interpretation of the existing business flow: downstream processes may have to listen  Product put on sale to start tracking. Waiting on Product Page Published instead could lead to unnecessary coupling and friction if different business flows are in place.