Identifying Boundaries between Teams

We already talked about how to structure teams for scale which advocated for having long lived teams aligned to parts of the customer journey with completely separate code bases. These teams get the benefit of being able to get a deep understanding of the customer needs in their area of responsibility as well as having the independence to deliver as needed.

But real products do not map to our over-simplified linear user journeys like the flow above. There are activities that can happen at any time, edge cases and exceptions that need to be handled, and there are often multiple paths that a user can take to achieve their goal. We need a technique to analyse our products and then identify the best suited boundaries for our teams.

Event Storming

Event storming is exactly what we are looking for. It is a technique for identifying the value streams and boundaries within your product. It is a workshop where you map out your entire end-to-end business process so that you can identify all of the “events”, “commands” and “actors” in order to gain a deep understanding of how your product works. And because you are mapping the business process, it is critical that you invite representatives from all impacted functions as well as the technical team.

Events

You start by listing every action that takes place in a system. Examples include things like Website Loaded, Search Entered, Search Submitted, Product Page Loaded, Add to Cart Clicked etc.

Commands

The next step is to document the actions that triggered the events to happen. This can either be an action that a person takes or it could be a system that triggers the event. For example, a person could trigger an event by clicking a button, or a change in one system could trigger an event in another system.

Actors

Next we list who is performing the action that triggers the event. This could be an end user but could also be different persona types, employees, other systems or business rules and policies that get triggered.

Walk Through

After you have created your event storming map it is really important to walk through the map to confirm that everyone is in agreement. This is usually where you find out about edge cases or misunderstandings about how the process works. Keep repeating the walk through after each round of edits until everyone is in agreement.

Improve the Process

Another benefit of creating a map like this is that it is often the first time that the wider business team have visibility of how the product works from end-to-end instead of just their part of the process. What tends to happen is that people start to identify inefficiencies, duplication and other issues with the process. If you spot these issues you should challenge the teams to improve and streamline the process before continuing.

Identify the Value Streams

Now that we have a representation of all of the events and activities that take place in our process we can start to identify the logical boundaries in our flows.

The first step is to identify what we call significant events. Things like Email Sent, Search Submitted, Product Added to Cart, Payment Submitted. These events shift the user along their customer journey so it can be useful to think about the core journey steps of Awareness, Consideration, Engagement, Decision, Action, Usage and Loyalty.

Once you have your significant events highlighted you can start to draw your first set of boundaries around the flow. This should involve a lot of discussion among both the business and technical attendees of the workshop. One potential pitfall here is that you create boundaries based on internal handovers but this is not necessarily the best logical boundary for your system - it’s just how people felt it was best to manage the process internally. Focus more on the customer and their actions over time.

While using the user journey as the starting point for your boundaries is useful, you’ll notice is that some bits don’t really fit neatly, and these tend to be around the edge cases. Things like marketing campaigns, user login, policy triggers and more are logically separated from the flow. Feel free to draw separate boundaries around these items.

Validate your boundaries

Finally, review the boundaries that you have created by running some example case studies through the flow. This will help you to identify where things are more connected than you previously realised or potentially less connected.

You can also review the last 5 feature launches to see how you would split up the functionality across boundaries. Are there some boundaries that are always connected and have to move together? If so, then these should be merged.

Event Storming Output: Value Streams

After completing the exercise you now have a list of independent value streams for your product. These value streams are both aligned to how customers think about our product as well as logically separated so that we can create separate code bases for each stream.

The next step is to determine how to create teams that will own and deliver on these value streams. But each stream is not equal. Some are large, some are small, some have a lot of business rules and complexity, some do not, some are technically complex and some are simple.

We’ll dig into prioritising and funding value streams in the next article.