The last article (here) was about how to conduct a virtual brainstorming. In today’s part you will learn how we do eventstorming, what preparation it needs and of course a lot of experiences. At the end you will learn about a practical case study.
Eventstorming is a creative technique we use to design our software and to get a collaborative big-picture on our products. The technique can also be used for other problems than software development, e.g. for deriving business processes, which is not part of this article. The goal of eventstorming is to detail a (program) vision so far that concrete development tasks can be derived. At this point we would like to point out that in this article we describe our experiences with a suitable adaptation of the eventstorming method. For example, we use sketches for visualization and play through workflows with the program from the user’s point of view. This method works very well for us and we would like to share our experience with you.
Each interaction with the program can be understood as a trigger for an event, and the event describes the change that resulted from the interaction. An event describes facts in a system. For example, if you click on the “save” button in your text editor, the action saves the document and the event “Text document was saved to disk” is created as a result. The event describes the change of state by an action. The “Text document was saved to disk” event is already very specific. To be able to execute it, you need a button, for example. Because of this change a lot of further activities can arise, processes can be started and actions can be executed. By playing through these actions and events you get an extensive picture of how your program could be used. This doesn’t sound new at first, because for example there is already the approach to formulate requirements, for example as a user story: “I as a user would like to be able to save my text document on disk”. The difference here is that you now only consider the user’s point of view and also stop at this point. But what about the software developer, the designer and all the other stakeholders, what exactly should they do now? Do they need to create an interface, a button? In eventstorming, a more comprehensive picture is drawn for your program and all the stakeholders included. So eventstorming is a method you can use when people with many different views and expertise come together in your workshop. And after your workshop, everyone has the opportunity to derive their specific tasks.
There are three phases in eventstorming. The first step is to create an overview and to get clear about people and their goals. In phase two you focus on processes, interaction possibilities, commands, and suchlike. So, you focus on the specific application. And in the last phase you rather deal with the system design by adding aggregates and deriving a context map (external link). We mention the last phase just for completeness. We are currently using Eventstorming to generate a deeper understanding of our software design and system landscape. For us, it is important to create a common understanding, which we can sufficiently derive after phase 2. We therefore do not cover phase 3 in this article.
Different colored sticky notes are used for each of these phases. The first time we did Eventstorming, we needed a huge wall and a hundred sticky notes. Now we do eventstorming online. There are good whiteboard solutions for this, in which you have many colorful electronic “sticky notes”. You can find a large selection of open-source whiteboards here. And if you need more information or tools related to eventstorming, you’ll find them here.
For phase 1 we use the following sticky note colors:
Orange for events, yellow for actors e.g a user and pink for external systems. External systems represent areas with which the program to be designed interacts, but which is not part of the program, e.g. an external cloud storage.
In this phase, focus on how you use your system and which relevant events are derived from it. Write these events on the orange sticky notes. Often, when you think about one action, the next one automatically arises and you “play through” your program several times. Let’s take again the example with the text editor and the save command. The user has pressed the save button, which opens the save interface. Expressed in events (orange) it could look like this (note: example contains errors, explanation follows):
Similar to brainstorming (link), it is also important to collect many event ideas. However, we do eventstorming purposefully, i.e. we do not include functionality that we do not want to implement in the first step. However, you can also keep it like brainstorming and think through all ideas. This can result in ideas that you had not considered, and which may be easy to implement. But don’t get lost, the overview quickly becomes very large.
In this first phase, external systems can also occur. If, for example, you do not want to write the text document to the hard disk, but to an online storage, this is not part of your system and is therefore written on a pink note. However, you record the events that are transferred from the external system to your system and are relevant for you, such as “File was locked by another user”.
If you have thought through all the functionalities of your program, there should already be quite a few sticky notes on your (hopefully virtual) board.
In the second phase, we use green sticky notes for inputs or views. Blue sticky notes are used for commands and purple sticky notes for rules. The goal of this phase is to model the steps that lead to an event. You will see that by the end you will have a very clear idea of the program you want to develop.
Separate the sticky note for the user and the following event. After the user, place the green sticky note. There you write the interface that the user will see and interact with. It helps us to sketch the interface with the relevant interaction possibilities. This gives all participants an immediate idea of what is being discussed. In the case of text documentation, it might look like this:
If you think of any other events during this step, write them down. It may also be that events become obsolete, in which case simply remove the corresponding sticky note.
The green sticky note is followed by the blue one. On this one you write down the command that leads to an event. In this case the “save document to disk” command. The notes could now look like this:
As you can see, the event “Save button pressed” has been removed. Pressing the button itself was not yet a change in the program system, but perhaps only leads to a visual change. When you start with phase 2 you will surely notice that several such wrong “events” have crept in. In time, you will recognize these false events immediately and not include them. Always consider whether a change is made in the program system or not.
Views do not always have to be full screen. Even an area of a page like a shopping cart or a product page in an online store can be a view in the sense of the green sticky notes. Therefore, there are often a variety of views that can be assigned to one user. However, each event always requires a command that triggers the event and usually also an associated view through which the command can be triggered. We therefore assign several green, blue and orange sticky notes to a user, which we arrange one below the other. Each event that you process in this way adds further partial views, buttons or lists to your interface sketch. In the end you will not only have all events, actions, views and people, but also a sketch of your program.
Wait, isn’t there something else missing? That’s right, the purple sticky notes. These represent rules. Now, when you click Save. A program rule will prevent you from saving if the document is protected. You write this rule on a purple sticky note. Place it between the command (blue note) and the event (orange note). When you want to execute the command, the rule is checked and only if the rule agrees, the command is executed and the event is created.
Then this would look like this:
From time to time, we also model a system as a “user” if it can execute commands independently and thus behaves like a normal user. The system typically does not need a user interface. If this is the case, we write down the system on a yellow note, stick the corresponding event next to it and in between the respective action (i.e. the colors yellow, blue, orange). You can imagine an agent system, which monitors other systems and intervenes if necessary.
As already mentioned, we will skip phase 3 at this point. In our opinion, the program is already described in detail by phases 1 and 2 and sufficiently detailed by the sketch of the interface. In the following steps, each division can now derive its work packages. More about the detailed planning in a later article.
In the last article, Mia, Peter and Zou performed brainstorming (link) and derived from it all the functions they would like to implement. Today they want to use eventstorming to specify their idea in order to be able to create work packages. Mia has already chosen an open-source whiteboard (link) and created different colored sticky notes. Analogous to the brainstorming, the three start collecting events. They identify people and describe external systems. An excerpt from this is as follows:
They immediately group the events logically to each other, thereby discovering more and more events and a first idea of their video chat emerges. After about an hour, they have all the relevant events together, identified some external systems and described people. A huge whiteboard has emerged, fortunately the sticky notes are easy to handle electronically. The three notice that the identical event can be executed by different people. As an example, a guest user can accept a video chat request, as can a registered user. The events for this are identical and are therefore assigned to both people. Therefore, they decided to duplicate the events and assign them to the different people. Based on the linear flow, they now create a tabular overview by duplicating the virtual sticky notes and assigning them to the different persons.
Mia, Peter and Zou now feel ready for phase 2. They take the first column and list the events one below the other. On the left they place the user and on the right the events. In between, there is space for the green, blue and purple notes. For each event, they now think about the view over which the person executes which command to trigger the event.
Time flies and another hour has passed quickly. Mia suggests a short break. Even though everyone is having a lot of fun right now, they agree with the suggestion because the concentrated work is still exhausting. After 15 minutes they continue. Zou has agreed to sketch the views, since she has an electronic pen. The contact management has already taken its first shape.
Mia, Peter and Zou still need several hours and many breaks for all events. In the end they have defined three views, the contact management, the meeting scheduling and the meeting execution view. With this they are satisfied for the time being and finish the eventstorming. Since it is already late, they decide to end the workshop for today and to postpone the finalization of the workshop to the next day.
In the next article you will learn how to properly finalize a workshop and how Mia and her friends handle it.
<< blogs