Embed event storming in your agile toolset

Event Storming has caught me by surprise in the way how it boosts a project’s startup and in the way the business can connect to it. I really enjoy the rare moment where a software development process really connects well to the business. It has a unique quality where it makes stakeholders and participants more equal. In a world dominated by technology and all these agile and DevOps processes that for most people are still ‘out of this world’ it’s nice to been offered a tool to be connected. But what happens after the high of an Event Storming workshop? The result will help you to shape your software architecture into domains and it provides a vocabulary shared amongst all stakeholders. But I would argue we need this alignment with a process as well. I will show how Event Storming concepts can be intermixed in the agile process.

The TL;DR of why you want to intermix event storming in your agile toolset is to achieve the following benefits:

• The Event Storming map is not just a fancy brainstorm, it fuels all input
• Improved identification of (business) domain concepts from vision to stories
• Remove potential ambiguities in backlog management
• Improve traceability of vision and high level objectives to stories

Why Event Storming

Before we can dive into the details of the flow. Let’s consider the role of Event Storming in an agile context. In the past few years Event Storming has gained popularity from the software development community. It is a workshop format aimed at capturing requirements in a domain driven design architecture. What I consider one of its strengths is the focus on the business stakeholders and the high level interaction the workshop provides. Such a workshop can be performed at any stage in a software delivery lifecycle, but my focus is primarily early in the life cycle as a requirements gathering tool. If you not familiar to this technique, there are some recommended readings at the end of the article.

So where does Event Storming fit in? The application of these tools is of course very situational. It largely depends on the maturity of the organisation, stakeholders, and the complexity of the domain. The most top-down or natural flow for me is as follows:

I will discuss the relation with the product vision board, story mapping, product backlog, and also how to relate this to your backlog. The goal for this setup is to align the ‘input gathering tools’ for a development team with the Event Storming results.

Product vision board

Creating software requires a huge amount of effort, and context is key in getting the right value from the money spend. Any significant iteration of a new or existing project should start with the ‘why’ question. A product vision board is a tool to capture the context of your undertaking on a high level. There are multiple formats, and depending on the situation it can make sense to pick one over another. A basic version is one from Roman Pichler. I will describe a basic example.

Creating a product vision board is a great precursor to an Event Storming sessions.A vision is only powerful when actively used. Working from a vision only works if you express it. Most teams would benefit from doing this more often. Here are some ways of using the process the product vision board in an Event Storming session.

• Tape the vision high-up on the wall above your Event Storming working area.
• Use the board to to discuss whom you want in the room for the Event Storming. Getting architects in an Event Storming room is easy. Getting the proper business stakeholders is much more difficult. There is also much more politics. Read the board and determine for each quadrant which stakeholder will represent the subject the best.
• Use the product vision board to kick-off the Event Storming session. You can verbally address all the stakeholders in the room, and tell them why they are part of the workshop because they will have some part in this product vision board.
• As a synchronisation effort — after a fair amount of progression (e.g. after lunch), discuss the product vision and benchmark and see if the results cover the product vision (and vice versa).
• There are some variants of Event Storming workshops. You can use the business goals section of the product vision to establish a feel for the size of the project. Based on this you can do a 30.000 ft overview workshop or something with more focus.

Story mapping

Story mapping is a great workshop technique to collaboratively create a backlog. It allows to discuss the breadth and depth of the product. As depicted below, most people use the horizontal axis to highlight logical groupings in your software (theme’s, components, high level process steps. This is sometimes called the skeleton, it functions as the backbone of you story map. Capturing this these high-level themes is often the first challenge. Without any guidance this can be tough and will often require rework once you start to learn about the software. The vertical axis is used to determine the order in which you want this work to be part of your product. Works items (stories, epics, etc) get placed related to a vertical swim lane when it belongs to the column. And the height on the board will be determined by priority or logical dependencies. Once everything is plotted, the final step can be to identify the most valuable smallest possible releases as a horizontal slice.

In some way the story mapping format is sometimes compared with Event Storming. However, I personally use it for a very different reason. While Event Storming is focused on the business, story mapping is aimed at work preparation. This way both tools serve a very different goal.

As mentioned before, getting the horizontal axis right is often very difficult. In regular story mapping (how most blogs prescribe it) I have learned it can make or break the conceptual picture of the system. People tend to use a conceptual model which is too low level, like a screen flow. I consider it a risk to focus the story map too much on solution properties. Things like screens, UX, or a process diagram will draw attention to the solution add hand. While designing towards a solution might look like something positive, it’s often too early to already have this solution in mind. This is a very important concept, so I will exemplify it. Let’s consider the story map below. Maybe it even looks familiar. Chances are that the stories depicted in this board are on your backlog right now!

A story map with little focus on business value

The flow depicted above is painfully recognisable. Unfortunately plumbing gets the lead role in many design session. So let’s take a step back. Your product vision will tell you why you want to build your product. The Event Storming workshop will tell you what the business looks like, and how to organise your software accordingly. In order to properly support the business with software, we should invent software which adds the most value!

So let’s reconsider story mapping. It’s a collaborative workshop aimed at work preparation, and has a focus on delivering the most value in an early stage. A perfect fit. All we need is a way to align this tool to the Event Storming. So let’s use the creative aspect of story mapping, and use it to describe solutions.

If you think about the Event Storming map. It describes a business process flow in time (left to right) and it shows contexts (DDD bounded contexts). So I use the contexts as the horizontal axis.

It has some advantages:

• Focus on business context
• Verticals are recognised by anyone who attended the workshop
• Allows for upwards traceability to track the source of requirements
• Contexts are by their DDD nature, strongly related to the implementation

It has some challenges:

• The time dimension does not always relate linearly to the business contexts. This is often a best-effort approach. Sometimes a context can be divided in sections. This works as long as it is semantically clear they belong together.
• The focus on business can draw eyes away from lots of necessary plumbing of the application.

Getting it on the backlog

Story maps are mentally easy to think about. It’s a great tool for mid-to long term planning. People in general are more comfortable with the two dimensional story map type of backlog. However, when it comes to prioritising and planning, a single list of backlog items often works best. In the end the ‘real work’ is on the backlog and detailing stories with designs, acceptance criteria, and non-functionals is often difficult on stickies.

I used to find it difficult to relate the reality of the backlog to the dreamy high-level pictures on the wall. Most backlog tools have advanced labeling features which enable you to provide attributes to stories like: epics, components, releases / versions, theme’s, and labels to name some familiar fields. These enable improved tooling support for monitoring and planning and help to organise the backlog. However, organising your backlog using attributes only works when you have chosen the proper attributes to tag your stories.

Component tagging or similar solution-focused tagging policies are cumbersome. You often start with a small list of components that everybody knows, and at that time it helps to divide the work in theme’s. Over time a team’s attention switches to other parts of the software, and you will need to add new ones. However, the total list of components consists of lots of things that are not relevant for you at that point in time. Few people dare to delete it, and it will grow and grow. I have seen people copying the top part of the backlog to a new one to start from scratch. Often repeating the same mistakes. I have come to realise that a focus on DDD concepts as an organisational dimension offers a strong organisational dimension to the backlog. I will not argue to skip the ‘old’ solution-driven components, they can easily coexist.

I used to have a problem with long running epics. Because epics are chosen at a moment in time where it makes sense to group some stories. They were often prone to prolongation, because somebody could always think of some story which would fit the bucket.

So my new policy for organising a backlog is as follows. I take a slice from my story map and combine each story with the release for this slice. So stories that are related to epics, that exist in a certain release. On delivery of the horizontal slice, every epic should be closed. I assign the vertical axis (a DDD domain concept) as a ‘component’ to both the epic and related stories. This way the business domain is represented and you introduced a timeless dimension to organise your stories.

Some final considerations

In the past I found it difficult that in the backlog in the end was a completely different world than all visual tools mentioned above. I ended up with a room full with hopes and dreams on brown wallpaper filled with stickies. In the first weeks you would reach out to it in discussions, but after a while it got outdated. I never felt these techniques where inadequate, but I did found it challenging on how to integrate it.

Then a year ago I worked with a team and found out how strong DDD can benefit software. After some time I tried to integrate these concepts to other tools mentioned in this blog. I think the immersion of a strong domain that is visible in all parts of your requirements elaboration has benefited the quality of input, and therefore the quality of our output.

I hope it can do the same for you.