Event Storming: Lean Product Or Service Modelling For Current Or Future State
Event Storming is a lean, rapid prototyping methodology in which the process is as valuable as the outcome itself. As with anything labelled “lean” the idea is to try ideas out, iterate, change and create a business or product flow that you can show your boss, team or investors quickly.
This is not the traditional approach of a product owner or business analysts canvasing the team for ideas over many weeks or longer and then interpreting what each of them means and then mapping out an unrealistic ideal.
The approach brings together all of the key stakeholders from developers to executives who have insight into the concern being discussed in one room at the same time. The stakeholders are guided by a facilitator to outline three specific aspects of the system at a very specific and neutral level of abstraction. Everyone uses plain English (or whatever language you are using), they speak about domain events – business level events that occur as the system moves through it’s flow. There is no technical jargon allowed.
The Three Elements Of Event Storming
The flows are made up of three aspects, each denoted by a different level of the flow and by a different colour. These are:
Top Row: Commands (Post-It Color - Blue): These are the points at which something in the system changes either due to user interaction or a change in another part of the system. e.g Process Payment. These are written in the present tense.
Middle Row: Events (Post-It Color – Yellow): These are the events that have occured in the system. As you develop your flow you imagine that the system has been in operation for a year. In that time, what events must have happened in order for the system to function in the way that you envision? e.g. Confirmation Email Sent. These are written in the past tense.
Bottom Row: Documents (Post-It Color – Pink): These represent the content that you want to show in the UI or when you run a query. e.g. Email, client name, items purchased, confirmation number. The are written in the present tense.
These three together show you when something happens, what happened and the context for the event.
Start With The End In Mind
What emerges is the flow of how the product or service will work. The team starts with the final outcome that the product or service is meant to bring about. e.g. “Confirmation Email Sent” or “Payment Processed” and works backwards outlining the business events that must have happened immediately before in order to make the next event happen.
Separating The Wheat From The Chaff
If there is anything missing or out of place, it will be obvious. Also, different stakeholders will have different opinions about whether something should be included, where it should take place in the system and the service boundaries of the microservices. These discussions and debates are particularly important
In the best “lean” tradition the merits of one approach over another can be debated at this early stage before a line of code has been written and a major investment made. Moreover, everyone who is part of the process feels heard and, through the process and the debates, gains a rich and deep understanding of what the team is building and why.
The Happy Path
Once we have determined what core value is that the system is meant to deliver we ask participants to brainstorm everything and anything that they feel is an event that must have happened in the system which lead to this outcome. Participants put their sticky notes up on the wall in the approximate order in which they feel the events takes place.
Once the amount of brainstorming has ground to a halt, we have one or more of the participants go through all of the events with the intention of outlining the “happy path”. These are the events that happen from start to finish, if the system worked perfectly.
Invariably, people put up non-events, events not stated in the past tense, duplicates or edge-case events. This is all part of the learning experience. Those laying out the happy path put duplicates on top of one another, move edge cases to the bottom of the board or wall and ask those watching to re-write events. As the happy path emerges those not working on the flow begin to critically review the events and their order through the lens of their own experience. Spontaneously questions arise, discussions ensue and THE order as determined by the group emerges.
The Importance Of Language
A word here about the importance of language. As the flow emerges and duplicates are piled on top of one another, it will become clear that participants will use different words to describe the same event e.g. user registered vs. member signed up.
Using the most descriptive and context-rich word is best since it brings the domain alive and may help to clarify what you as a company offer that is different from what others provide. Once you have determined that using the word “member” is preferable to “user” for your online investing club we recommend you use this consitently throughout the event storming. In parlance of Domain-Driven Design this is called “ubiquitous language”. Most importantly, using specific words for different actors in the system will often offer clues as to where the boundaries of the microservices (or bounded-contexts) should be.
- is a modelling exercise codified by Alberto Brandolini
- leverages the principles of domain-driven design
- is done in person, with key stakeholders
- specifies what business events must take place in order for the system to function in the way that the team envisions
- is done in a room with either a role of paper or on a wall
- events, commands and documents represented by different coloured post-it notes
- the result is a step-by-step walk through that tells the story of the system
- forces stakeholders to debate the merits of events and the business and technical implications of putting them in a specific order
- captures business events in a way that doesn’t specify a particular stack or implementation
- keeps everyone focused on a very specific level of abstraction
- creates a shared understanding among both business and technical stakeholders of what we’re building, why we’re building it the way we are and what value it creates without writing a line of code
- defines the solution architecture and boundaries of microservices
- swim lanes can be turned 180 degrees and turned into Kanban boards
- swim lanes of features allow for parallelization of work