As we can see, our simple model already provides quite a lot of value to people involved in the workshop. Not only we tried to identify what happens during the process of a bill being paid, but we put the whole flow on a timeline and were able to roughly identify parts of the process that can happen in different physical systems.

Visualization is one of the most powerful aspects of any modeling technique, and EventStorming is not an exception. As soon as we put something on our model, we can reason about it instead of just pronouncing words and waving hands.

When people see what is considered the "whole picture," some might start asking questions like what if. What if there is not enough money on the account? What if the bill reference number is wrong? What if the payee account is not correct? What if, what if, what if??? It then appears that our simple process is not that simple by the end of the day. Remember the availability heuristic, WYSIATI (What You See Is All There Is)? We base our initial understanding on a simplified view of the world. Everything works as it should, there are no exceptions and no edge cases, people behave and don't plan to make mistakes, with or without intentions to do so. It might come as a surprise, but the real world is a bit more complicated. Most of the time the number of edge cases exceeds the amount of what is considered to be a regular flow of events. All these edge cases and potential exceptions become much more visible when things get visualized and are brought to daylight for everyone to observe.

There is one issue here, which can do a disservice to those who are trying their best to create a proper events model. You could imagine that such a workshop happens in a meeting room. Usually, people sit around some table and talk. As we already discussed, this is not how EventStorming works. We expect people to move around the room and be actively engaged in conversations, which might happen simultaneously at different sides of the room. So, we need some space. But this is not all the space we need. Have a good look at the simple process model above. Although we all could agree that we just modeled the happy path and no edge cases and exceptions are covered, that the real-life process is way more complicated; this diagram already takes some horizontal space. Now, imagine real-world scenarios being modeled like this. Indeed, a traditional two-three meters wide whiteboards would do a disservice for you.

Imagine your model like this:

Here in the middle is your whiteboard. But the model is not that small. As Alberto says, my problem is bigger! 

What happens, when there is not enough space left on a whiteboard? People treat the space left as a sacred resource. It becomes precious, and people start saving space. Some events become "not important" and therefore not put on the whiteboard. Some ideas become secondary and not worth looking at. All in all, the modeling discussion suffers in order to save some whiteboard space.

It is normal, and this is how our brain works. If we see some limit, no matter how silly or artificial it will look like in retrospect, we will feel its physical presence and will also set up our activities accordingly. If you got a limited modeling space—prepare to get a limited model. So beware of this issue and provide as much modeling space as you can for participants of any modeling session and of EventStorming meetings in particular. We will get into more specific advises in the next section.