Working Together — Chapter #2: EventStorming
Discovering the core domain by developing a shared knowledge around the project
Working Together is a series of articles telling the story of a fictional start-up living in my brain. We follow Bizz, the business manager; Paul Olivier (PO), the product owner; Junior, the junior developer; Senior, the senior developer. Each chapter highlights a specific process of product development.
In case you missed the 1st chapter : Chapter #1: Impact Mapping
Junior walked into the room to attend this second workshop. No one. No chairs, just a small table. Believing he had made a mistake, he turned back.
— This is the right room, said Paul-Olivier who had just joined him. Let’s wait until everyone arrives, you’ll understand better.
Senior then arrived, closely followed by Bizz who closed the door behind him and spoke:
— Welcome to all. As I mentioned in the previous workshop, we’re going to develop a project that will serve as a common theme for our posts. I am the business expert here, in the brain, that makes me a memory expert. We will create a small memory application using “spaced repetition”. It is a method that allows you to learn more by reviewing knowledge just before you forget it.
— I don’t quite understand what it is…, said Junior, doubtful.
— That’s the whole point of this workshop! exclaimed PO. We are gathered in this room to explore our core business, to develop a shared understanding of the project as a whole. But please, Bizz, explain to us what this “spaced repetition” thing is.
— It’s straightforward. It is a system developed by Leitner in the 1970s. In concrete terms, it consists of a box, separated into several partitions. The partitions contain some flashcards, with a question on the front and the answer on the back. All flashcards start in the first partition. When we review a flashcard and give the right answer, we must put the flashcard in the next partition. If we give a wrong answer, the flashcard returns to the first partition. We review the flashcards in the first partition daily, the second partition every two days, the third partition every three days, etc. By doing so, we revisit less known flashcards more often than the others. That is the principle of learning by spaced repetition. We review at the moment we were about to forget the answer.
— Just tell it if we are bothering you PO! exclaimed Senior.
While Bizz was explaining how the Leitner system works, PO went to the wall to place a sticky note:
— I know what a Leitner system is, responded PO, it’s the opportunity to start our workshop! I just put down the first sticky-note to serve as an example. As you can see, I formulated these words in a passive form: it is an event. The workshop we are doing today is called EventStorming. We will try to discover the events that can occur during the use of our application. Here I indicate that a flashcard has been added.
— A flashcard? asked Junior.
— That’s the name given to this type of card, replied Bizz.
— Never heard of this term in my life before your explanation of this “Leitner system” thing, says Senior.
— Only one sticky-note and we are already moving forward, says PO. One of the main goals of EventStorming is to create a common language, which all team members can understand. When everyone talks about the same thing for the same concepts, misunderstandings become rarer.
— This flashcard does not live in a vacuum, said Junior. Haven’t you forgotten things before? Bizz mentioned some “box” earlier. It must have been created previously, right?
— Exactly, replied PO. I deliberately put an event that does not mark the beginning of the workflow. The goal is to complete together what happens before, and what happens after. So you can add the « box created » event on the wall before the « flashcard added » one. We are trying to sketch the linear progression over time of our workflow.
Junior did so:
— If I correctly understand, says Senior, the user is invited every day to start a new review session. So we can also add this event:
— When the review session starts, a deck is created based on the schedule, said Bizz. If it’s the first day, we will take the flashcards from partition 1, if it’s the second-day session we will take from partitions 1 and 2, from partitions 1 and 3 for the third-day session, and so on.
— To know what revision day we are on, we will also have to determine the first day, the one that will serve as the starting date for the box, PO pointed out. Should we consider the creation date of the box as the first day, or should we use the day of the first review session started by the user? Let’s put these events and questions on the wall:
« As you can see:
- the orange sticky-notes represent the events
- the pink sticky-notes are used to highlight questions and remarks
- purple sticky-note notes indicate business rules
When two events occur at the same time, we place them one below the other.
— The next step is to review a flashcard, called Senior, the user will have to pick it from the stack created for this session. I think everyone will agree that we pick the first flashcard in the stack:
— Once the user has picked the flashcard to review, said Junior, he should be able to see the associated answer, and then notify if he had the right or wrong answer. So I see three new events:
— The last two events are relevant, PO noted. On the other hand, the « answer shown » event is not relevant to our model. It does not represent a state change in the system. Instead, this represents data that the user needs to make an action. An action based upon that data. For this example, the user needs to see the answer to notify if he had the right answer or a wrong one. I’ll add a green sticky-note underneath. It’s a notion we’ll talk about later:
— The next step might be incrementing the score if the user has given a right answer, said Bizz. The flashcard should be moved to the next partition if the answer is correct, or put back in the first partition if the answer is wrong:
— The two events about moving the flashcard seem redundant to me, said Senior. We could use only one sticky-note. In code, the partition number will probably be represented by a variable in the event.
— Fair point, said PO. But let’s not think immediately in « code », it’s better to be able to represent the different events explicitly as a starting point. Even if, eventually, we will merge them into a single event.
— What happens if you give the right answer to a flashcard that is already in the last partition? asked Junior.
— It gets archived, replied Bizz, meaning this flashcard is now stored in the user’s long-term memory, hopefully.
— Okay, so we need a new event, Junior added. I’m going to place it on the wall:
— When we review the last flashcard of the current session, the session ends, said Bizz by adding two sticky-notes:
— Here we are with a first version of the workflow! said PO. We have in front of us all the state changes in our application. The next step is to understand what triggers these state changes. It is often the result of a user’s action, and users need to rely on some data to make their decision. We’ll see how we can represent that. I suggest that we take a short break and continue with this step right after!
To be continued…
