Use this tool whenever you want to:
- Understand or document the domain of your project
- Translate domain knowledge to software
- Map any kind of process
New project, new me
You are starting a new project. Feels good, right? Yes! This time no mistakes, right? Yes! You are going to use all of your development experience from previous projects to make this project an exemplary one, right? Yes!
Wrong! Here’s the news, Jack: Your developer skills are not the thing that actually breaks the project. But you know what is? Requirements. More specifically, unknown requirements.
If you don’t know the project requirements, things will go south once again, believe it or not.
The Domain
Understanding the domain is what makes or brakes the project. It affects your estimations, it affects your risk management, it affects your relationship with project stakeholders. It affects so many things.
Now, there are a lot of ways you can document your project requirements, but not a lot of tools to explore the domain and map out the business processes.
Eventstorming
Eventstorming is a tool for mapping processes. It was created with software development in mind, but really, you can use it for any process that can be described by a series of events.
Example #1
For instance, reading this article can be described by events:
- article is opened
- visible text is read
- next chunk of text is scrolled to
- next chunk of text is read
- like button is pressed (this one is not really necessary) :)
Example #2
Let's try another one. Login:
- username is entered
- password is entered
- submit button is clicked
- Text "Hello, Rudolf" is visible
Events FTW
So, events are the focus of this tool. At least at the beginning.
Now, these examples are simple and we can probably fit more events and ask a lot of questions, right? Yes, but this is exactly why this tool is great and where the fun starts. And also magic :)
You can create an overview of the process you are exploring or go into details. You can focus on a specific part that is complex or unknown or most important. Or map everything, that is, if you have time.
You said time, I don’t have it.
Great, because the main point is that learning about system by writing code is a very expensive way of understanding business processes.
You got my attention, how do I proceed?
To start, you need to gather domain experts and have them onboard. They are the ones who know the domain, but they usually have it inside their mind.
You should have a facilitator, someone who asks great questions and is curious. Yes, you can play that role.
You also need post-it notes in different colours and a big surface (wall or paper) to place those post-it notes.
Let's begin, finally
It starts by writing down the first and the last event of the process. For example, let's say you are mapping the online shopping process. You start with something like Item is added to cart and end with something like User received the product.
There is a simple rule for events: Events should be written in past tense, as if they already happened.
Now, Eventstorming can be done offline (the original idea) as an event where people of the domain gather physically and work together to map the process. Or you can use an online tool like Miro or something similar.
Once you have the first and the last event, you encourage people to write events to orange stickies and put them on the surface.
So far so good
Now you watch the magic happening. Questions about the ordering pop up. What comes before and what comes after. How do pieces connect? People learn about other parts of the domain. Some questions cannot be answered at this moment. No problem, put the red sticky and mark this part as the (known) unknown.
And how can I pitch this idea to my manager?
You should learn more, test it for yourself first. But if you need to communicate benefits, here are some:
- Visualisation of business processes
- Clarity and structure emerging
- Cross-department learning
- Mapping the unknowns
- Key questions pop up
How can I learn more?
As I said, eventstorming is invented with software development in mind. More specifically, with an approach known as Domain Driven Design.
The beauty of this process is that it can help you with understanding the systems even if you don't use DDD.
As you dive deeper into the process, new stickies and new terms popup. Like Policy, Command, Input, Aggregate and others. You can begin with Event and Policy and build on top of that.
Policy is a business rule. It usually looks like Whenever then
Command is a decision that usually triggers some event. For example, Add item to cart. It triggers the event Item added to cart
You can use this legend to help you with the process
Eventstorming is a very powerful and very simple tool for exploring your project domain and translating it to software code. And you are going to love it!
Top comments (0)