Ensuring Consistency Between Value Streams and Event Storming
Introduction — How VSM and Event Storming Relate
A “Value Stream Map (VSM)” describes the flow of value that the customer (the service consumer) experiences, from ”an outside-in perspective”.
It is a strategic map that clarifies “what” should be achieved and “why”.
In contrast, “Event Storming (ES)” describes the business processes executed by the service provider to realize that value, from “an inside-out perspective”.
It is a tactical blueprint that explains “how” the value is delivered.
About Analogy
The relationship between VSM and Event Storming is similar to the relationship between a building’s external architectural rendering (VSM) and its internal structure—steel frames, beams, plumbing, and wiring diagrams (Event Storming).
No matter how impressive the exterior is, if the internal structure is messy or fragile, the building is not valuable.
How Do We Ensure Consistency?
The key is to intentionally map the two models together.
The most effective approach is to align “each value stage” in Value Stream with the corresponding “key domain events” in Event Storming, ensuring an end-to-end match.
Relationship Between the Two Models
VSM Model
Assume the VSM defines stages such as: “Order Accept” → “Inventory Check” → “Product Shipping”
Each green sticky note represents a value stage.
Event Storming Model
In the Event Storming output, there must be domain events such as: “Order Accepted” → “Inventory Confirmed” → “Product Shipped”. These domain events must exist as clear boundaries (context cut lines).
In other words, VSM works as a strong guide that defines “which scope (context) Event Storming should focus on”.
1. Qualitative Check — Consistency by Design
“A qualitative check that each value stage represents the value delivered by its bounded context.”
This is the core of both architecture design and organization design.
Why does it matter?
- A value stage is a meaningful “value boundary” from the customer’s point of view.
- A (bounded) context is a “responsibility boundary” for development teams and also a “deployment boundary” in software.
If these don’t align, then “customer value” and “team responsibility” are misaligned.
This almost always creates cognitive dissonance between the intended business domain boundaries and the actual architecture boundaries.
As a result, the misalignment between the original cognitive boundaries and the architectural boundaries almost inevitably creates cognitive dissonance. (At that point, it is effectively business debt.)
For example, to deliver a single value stage like “Order Acceptance,” it may end up in a situation where complex coordination is required across three different teams (contexts), as illustrated below.
These three fragmented communication paths can directly decrease the customer value in the first place.
In this diagram, if Teams A, B, and C are collaborating asynchronously, it is essentially a worst-case scenario.
Best timing to check
My recommendation is to address this during Sprint Planning and Backlog Refinement.
How to check
- Place VSM and ES outputs side by side (physical wall or digital boards like Miro).
- When discussing a new user story or epic (the largest unit of functionality to be implemented in the software), always ask while looking at both models:
- “Which stage in VSM does this story contribute to?”
- “And which bounded context (owning team) in ES is responsible for delivering it?”
- If one VSM stage spans too many ES contexts, that is a strong signal to:
- This is a strong signal to either or re. The issue should be fixed immediately in that session.
- Revisit the architecture (bounded context boundaries), or
- Organize team ownership boundaries (reverse Conway’s Law.
In such cases, it should be corrected immediately on the spot.
2. Quantitative Check — Consistency in Operations
“Data-driven review using value metrics”
This verifies whether the “design-time hypothesis” matches “runtime reality”.
What are value metrics?
Metrics that measure how fast and smoothly value flows through each VSM stage, for example:
- Lead time: elapsed time from stage start to stage end
- Process time: time actually spent working
- Wait time: lead time − process time (value stagnation)
- Flow efficiency: process time/lead time (smoothness of flow)
(There are other value metrics as well.)
Best timing to validate
Sprint Reviews and quarterly Business Reviews (QBRs) are ideal for this.
How to validate
Event Storming outputs (e.g., “Order Accepted event ”, “Shipment Completed event ”) are the measurement points for these metrics.
- Design the system so that it captures timestamps for each relevant domain event.
- Use those timestamps to build dashboards, and review them together with the development team and business owners during the Sprint Review.
This enables discussions like:
“This sprint, we focused on improving the ‘Payment’ context.(Design / Development)
As a result, the wait time in the ‘Payment’ stage in the VSM dropped from 24 hours to 2 hours. (Quantitative outcomes)
That is measurable customer value.”
In this way, it becomes possible to discuss—using a shared set of metrics—how the development team’s activities (ES) contributed to business value (VSM).
Signals That Consistency Has Broken
When the consistency between the “exterior” (VSM) and the “internal structure” (ES) breaks, the business system will distort, and the distortion will appear as both qualitative and quantitative signals.
Qualitative signals
These are subjective, but strong indicators that people involved in the system feel “something is wrong”.
- Customer complaints
- Signal: “Order is done, but no confirmation email arrived.” / “Status stays ‘processing’ forever.” These kinds of questions come in constantly.
- Interpretation: a critical gap exists between the expected value flow (VSM) and the actual system process (ES).
- Business stakeholder frustration
- Signal: “Why does adding a discount rule take three months?” Business stakeholders start voicing dissatisfaction.
- Interpretation: the “Pricing” value area in VSM is likely spaghetti across multiple domains in ES (internal structure), making change difficult.
This suggests the value (VSM) and the structure (ES) boundaries are misaligned.
- Team confusion
- Signal: “Who ultimately owns ‘Returns Processing’?”/ “How far does this change impact the domain, ultimately?” This kind of discussion becomes common inside the development team.
- Interpretation: the “Returns” value unit defined in the VSM is misaligned with the context boundaries in Event Storming (i.e., the teams’ ownership boundaries).
Quantitative Signals
If consistency breaks down, metrics can surface an alarming reality—for example, the development team remains fully utilized (ES), yet the customer value lead time (VSM) does not improve at all.
These are measurable, undeniable indicators that value is not flowing through the system as “intended”.
- Lead time / Cycle time degradation
- Signal: VSM expectation is “order-to-ship within 24h”, but the actual measured time is 72h (based on event timestamps).
- Interpretation: the clearest signal that VSM (expectation) and ES (reality) diverge; an unexpected bottleneck exists in the internal process (ES).
- Low flow efficiency (High wait time)
- Signal: analysis shows an average 8-hour wait between payment approval and shipping instruction.
- Interpretation: VSM assumes smooth flow, but ES reveals dams such as batch processing or manual approvals.
- High error/retry rate at a specific step
- Signal: error rate exceeds 5% in payment execution policy or Payment Gateway integration.
- Interpretation: the customer value journey (VSM) is repeatedly interrupted by fragility in the internal process (ES).
Alerting Mechanism
If business stakeholders cannot participate in Event Storming directly, you must still implement alerting.
When these signals are detected, it is the best time to place VSM and ES side by side again and ask: “Are our blueprints drifting away from real value delivery?”
Summary
It is important to design the system so that each value-stage unit matches the granularity of each bounded context boundary in Event Storming.
This is not only a top-down loop (VSM → ES), but also requires bottom-up iteration (ES → VSM).
If collecting quantitative data is too costly at first, start with qualitative signals.
Even then, continuously and critically ask: “Are the VSM and ES artifacts still consistent today?”
This quiet, continuous work is how you recover debt before it grows.