Understanding a system with Event Storming

Today at leanovate we developers had our third session of "Continuous Learning" - our day-long commitment to learning.
One of our goals was to understand the system we are trying to build with a workshop format called "Event Storming". So what is Event Storming? It is a group learning session to explore a domain of a business or software and understand its complexity early on in the development stage. The goal is to produce a timeline of events, their origins, domain objects and what boundaries they exist in. Ideally the storming takes place amongst representatives of the domain e.g. customers, experts from the business, external institutions involved in domain activities (any stakeholder really). They are the experts who will help you discover the domain.
Not having those representatives around, we started by splitting into groups: domain experts, developers and customers. By having groups with different needs and perspectives on the software we avoided having an exclusively technical view. Then we started discussing the different events in our system and started to ask questions. For example "What creates an order in our system?", "What happens when the order is complete?" or "What should happen when the order is not paid in X amount of time?". Putting these questions in the room sparks fun discussions which can lead to other questions. It helps to have a moderator which guides the group and keeps the focus on the important questions to complete the modelling process.
After we agreed on the flow we placed a post-it either for an event, command or external system on a whiteboard. Then, we identified follow up events or aggregates, which could react to this event and in turn produce new events. By placing post-its for events and domain objects and discussing them we could find words which have different meanings to different roles in the project. For example an "order" could mean something different to the Sales department than to the warehouse department. It is important to find these differences because they help you to find boundaries in the domain.
At the end of the session you will have established a timeline of events and boundaries with which you can start your development. As a bonus you have established a common ubiquitous language among experts and developers, which will be used in following conversations in the development process. This perfectly aligns with domain driven design and should help you to start working with a clear picture of the domain model.