EventStorming Team Flow

Task boards are a great tool for helping teams visualize and coordinate their work, but they don’t show the full picture. Typically they only focus on flow of work for an individual team, ignoring upstream and downstream impacts and dependencies, and often without taking a customer-focused perspective. Also, they often tend to ignore wait states for work items rather than making them explicit on the board.

For those familiar with value stream mapping, EventStorming can function as a lightweight, collaborative, first-pass approach to visualizing a value stream and a team’s place within it.

EventStorming can function as a lightweight step in the direction of value stream mapping. The conversation that it enables and the map that it produces "can function as a visual unification tool, by enabling a team to visualize work that’s not particularly visual."

As with the visualization applied in value stream mapping, visualizing the invisible work is "an essential first step to gaining clarity about and consensus around how work gets done. It’s also a highly unifying activity - helps people see the need for improvement, and generates alignment and consensus around specific improvements being considered." - Value Stream Mapping.

The goal is to visualize queues so they can be managed effectively, starting with the ones that have the most significant impact economically.

As with regular EventStorming, the team performs an initial brainstorm where everyone writes as many events as possible at the same time. I recommend you map out the events that occur from an initial feature idea, all the way to the point where the delivered functionality is used by a customer to solve a problem or meet a need. Don’t worry about possible duplication or event sequence at this point where everyone is writing events.

Events are written in the past tense, as if everyone is looking back on the completed process. For example, write "story estimated" rather than "estimate story," or write "changes pushed to production" rather than "push changes to production."

Once you have a good representative sample of events, arrange them chronologically in sequence, earliest on the left to latest on the right. Don’t worry about loops or conditionals…​just lay it out as if it’s a linear flow. It’s more important at this point to capture the overall sequence rather than various possible paths. Eliminate any duplicates, though keep an eye out for differences in terminology for events as they may be significant in terms of uncovering different perspectives or misunderstandings.

Use another color to represent possible/potential queues in the process. Look for anywhere there is:

For every queue, talk it through as a team in terms of how much of a friction point it is for the overall flow. Are there simple ways to reduce the time that work spends in that queue?

The goal is to NOT to eliminate all queues but to manage and constrain them.

Capture any problems, questions, hotspots or conversation points on bright colored stickies. For example, if you find an event that is frequently associated with rework, it would be a good one to call out as a problem area for future investigation/experimentation.

Identify the queue with the most significant economic/productivity impact. If you don’t know which it is, start measuring it. Begin gathering data on problematic areas, and then run small improvement experiments.

Some possible tactics for managing an emergent queue to improve overall flow:

See also my Modeling Team Flow talk at Explore DDD 2018 for a slightly updated version of the Newcrafts talk. I also mention a number of other techniques for managing and constraining emergent queues.

I also introduced this technique at last year’s EventStorming Summit in Bologna. I learned there that others had already experimented with similar approaches using EventStorming in the past, so please let me know in the comments if there are other articles or talks that should be referenced:

Here’s a example Jenny Martin posted of applying this technique in a workshop:

If you map an entire value stream flow from "concept to cash" it is common to notice how small the development team part of the process is, and it is possible that the most damaging queues in terms of economic impact are upstream or downstream from the team. Once everything is mapped out, for non-trivial flows a common comment I hear is: "I had no idea we had so many queues."

I’d be interested in hearing about anyone experimenting with this approach, such as for a team retrospective or workshop. I haven’t tried to be comprehensive here, as I’m interested in learning what questions/feedback others have. What do you think? Feel free to post in the comments below.