Intro

This article defines the core Value Stream concepts used across the Value Stream Thinking (VST) pages. It clarifies Value Streams, Sub-Streams, and Value Stream Landscapes, introduces major Value Stream classifications such as Operational, Development, and Domain Value Streams, and explains structural relationship patterns including Nested Value Streams and Value Stream Networks.

The goal is conceptual clarity: these definitions establish a shared language independent of specific frameworks, while remaining compatible with approaches such as SAFe and beyond.

Core Concepts

Value Streams

A value stream is a coherent end-to-end flow of work that is triggered by a customer need and results in a valuable outcome for one or more clearly identifiable customers.

It spans concept, creation, integration, delivery, and realization of value within a defined system boundary. A value stream includes the people, processes, information, technologies, and coordination mechanisms required to transform inputs into outcomes.

A value stream is a flow-based system. The nature of this flow – stable and repetitive, iterative and learning-driven, or service-oriented – depends on the character of the value stream and the context in which it operates.

Depending on scope and abstraction, a value stream may contain smaller value streams (sub-streams) that contribute to its overall outcome.

Sub-Streams

A Sub-Stream is a value stream contained within a broader value stream. It delivers a defined intermediate outcome that contributes to the overall outcome of the larger system. A sub-stream has:

• a clearly defined scope within the broader system boundary,
• identifiable (often internal) customers,
• and its own end-to-end internal flow.

Value streams are recursive structures: a value stream may contain sub-streams, which may themselves contain further sub-streams.

Whether something is modeled as a value stream or as a sub-stream depends on modeling purpose, chosen scope, and degree of abstraction. A sub-stream is a modeling construct and does not necessarily correspond to a separate organizational unit.

Value Stream Landscape

A Value Stream Landscape is a modeling construct that makes multiple interacting value streams and their relationships visible within a chosen system boundary. Its primary purpose is to make the relationships and interactions between value streams explicit. Depending on perspective, it makes visible:

• alignment and shared outcomes,
• integration points,
• cross-stream dependencies,
• structural boundaries,
• coordination and synchronization dynamics.

A landscape does not replace value streams. It makes their interaction explicit.

Value Stream Landscapes are discussed in detail in the article: Understanding, Designing, and Steering Value Streams at Enterprise Scale.

Value Stream or Value Stream Landscape?

Whether a system is modeled as a Value Stream or as a Value Stream Landscape is a modeling decision that depends on:

• Perspective – What question are we trying to answer?
• Scope (System Boundary) – What is inside and outside the model?
• Degree of Abstraction – How much structural and flow detail is represented?

The same underlying system can legitimately appear as a single Value Stream or as a Value Stream Landscape, depending on modeling intent. These are not different realities, but different modeling choices. The choice of modeling perspective determines what becomes visible and what remains abstracted.

When developing a vehicle model series, the system can be modeled as a single Value Stream focusing on end-to-end delivery performance. The same system can also be modeled as a Value Stream Landscape when Domain Value Streams and their synchronization, dependencies, and coordination dynamics are made explicit.

Classification of Value Streams

Operational and Development Value Streams

Operational and Development Value Streams represent two common archetypes of value streams, distinguished by the type of outcome they deliver and the nature of their flow. This terminology is widely used, particularly within the context of the Scaled Agile Framework (SAFe)¹.

In simple terms:

• Development Value Streams (DVS)² build solutions
• Operational Value Streams (OVS)³ sell, deliver, and support those solutions for the organization’s customers.

Here are some common examples of Operational Value Streams:

Operational Value Streams are commonly illustrated in formats like the one below:

Development Value Streams are the engines that create the solutions an organization delivers – whether directly to customers or as enablers of internal operations.

These streams encompass all activities required to conceive, design, build, integrate, test, validate, and enhance solutions.

A Development Value Stream may deliver:

• Pure software solutions
  e.g., a mobile banking app, an enterprise CRM system, a cloud-based analytics platform
• Pure hardware products or components
  e.g., a battery pack, a braking system, a chassis module, a medical device component
• Cyber-physical systems combining hardware and software
  e.g., a vehicle infotainment system, an ADAS control unit, a smart home device
• Platforms or enabling capabilities
  e.g., a cloud hosting platform, a payment processing platform, a shared authentication service, a CI/CD pipeline platform
  

Development Value Streams are typically more iterative and learning-driven than Operational Value Streams, as they must progressively refine, integrate, and validate evolving solutions.

Development Value Streams can be visualized using high-level flow representations that illustrate major stages such as concept, build, integrate, test, and release. Such visualizations may also include potential flow metrics (e.g., flow time, deployment frequency, defect escape rate) that help make performance characteristics visible.

A more detailed and structurally precise way to model Development Value Streams is the Assembly Line model, which makes integration points, feedback loops, quality gates, and stage-specific performance measures explicit. The model can be applied at different levels of abstraction – from high-level value stream landscapes down to the detailed modeling of individual sub-streams. This enables holistic modeling of large and complex value stream systems while allowing targeted drill-down into any specific sub-stream or integration stage as needed.

Modeling approaches and their implications are discussed in the article Why the Way You Visualize Value Streams Matters.

Domain Value Stream

A Domain Value Stream is a value stream operating within a specific technical or functional domain that delivers a coherent domain-specific outcome to one or more consuming value streams.⁴

In automotive development, examples include domains such as ADAS, Infotainment, Powertrain, or Chassis.

A Domain Value Stream:

• has a clearly defined domain-specific outcome within the enterprise system,
• serves identifiable customers (often internal, such as vehicle programs or model series),
• maintains its own internal flow of development, integration, and validation,
• and may contain multiple internal value streams or sub-streams.

A Domain Value Stream is defined by the coherence of the outcome it delivers – not by size or organizational structure – nor by the number of teams involved.

Whether something is considered a Domain Value Stream depends on the chosen enterprise boundary and modeling intent. What is a domain sub-product for an OEM may represent the final product for a supplier.

Domain Value Streams are themselves recursive structures. A domain may contain sub-domain value streams that deliver coherent sub-products within the broader domain context. Whether these are modeled as internal sub-streams or as independent Domain Value Streams again depends on the chosen scope, abstraction level, and modeling purpose.

Domain Value Streams are discussed in detail in the article: Understanding, Designing, and Steering Value Streams at Enterprise Scale.

Relationship Patterns Between Value Streams

Beyond classification, value streams can relate to each other in different structural patterns. These patterns describe how value streams interact, align, and coordinate within a broader enterprise system.

The two primary relationship patterns are:

• Nested Value Streams
• Value Stream Networks

These are not different types of value streams, but different ways in which value streams can relate to one another depending on product scope, demand structure, and coordination needs.

Nested Value Streams

Nested Value Streams describe a relationship pattern in which value streams function as coordinated sub-streams within a shared higher-level value stream and are jointly dedicated to delivering a specific, bounded product scope (e.g., a defined version, variant, release, or product class).

In this pattern:

• The higher-level value stream represents the end-to-end delivery of the product scope.
• The contributing value streams operate as sub-streams within that larger flow.
• Integration points and milestones are synchronized.
• Planning, validation, and release activities are closely coupled.
• Success criteria are shared across the contributing streams.

The individual contributions of the nested value streams create value only once they are integrated and validated together within the shared product context.

Nested Value Streams are characterized by high alignment and tight coupling. Optimization at the sub-stream level must be evaluated relative to overall system performance, since delays, quality issues, or rework in one sub-stream directly affect the larger flow.⁵

Nested Value Streams provide a useful lens when the primary question is: How effectively do coordinated sub-streams work together to deliver a specific integrated product scope?

Example: When developing a specific model series, the ADAS, Infotainment, and Powertrain Domain Value Streams align their development, integration, and validation work around the needs of that vehicle. Their individual sub-products only create value once they are integrated and validated together within the vehicle context.

Value Stream Networks

Value Stream Networks describe a relationship pattern in which multiple value streams operate with distinct missions and serve multiple consumers, while remaining connected through defined customer–provider relationships.

In this pattern:

• Each value stream maintains its own product scope, roadmap, and internal flow.
• Value streams serve multiple downstream consumers.
• Coordination occurs primarily through interfaces, integration contracts, and service relationships.
• Alignment is maintained at portfolio or enterprise level rather than through shared delivery cadence alone.

Value streams in a network are more loosely coupled than nested value streams. They may collaborate and align strategically, but they are not jointly dedicated to delivering a single integrated product scope.

A Value Stream Network may contain a combination of independently operating value streams, nested value streams dedicated to specific product scopes, and shared domain value streams that act as nodes serving multiple consumers. Nested and networked relationship patterns are therefore not mutually exclusive and may coexist within the same enterprise system.

This structure is typical when value streams deliver reusable platforms, shared services, domain capabilities, or components consumed by multiple independent product streams.

Value Stream Networks provide a useful lens when the primary question is: How effectively do value streams within a network serve multiple consumers while maintaining coherence, quality, and flow performance?

Example: A payment processing platform may serve multiple digital products. A shared cloud infrastructure platform may support various application development value streams. In automotive contexts, a domain value stream may deliver sub-products to several vehicle programs in parallel.

Interplay of Domain, Nested, and Network Patterns

Domain Value Streams describe a classification based on the coherence of the outcome they deliver. Nested and Networked Value Streams describe relationship patterns between value streams. These concepts operate at different levels. A Domain Value Stream may function as a coordinated sub-stream within a Nested Value Stream when viewed from the perspective of a specific product scope. The same Domain Value Stream may appear as an independent node within a Value Stream Network when viewed from an enterprise or multi-consumer perspective. Whether a value stream is interpreted as nested or networked therefore depends on the chosen system boundary, modeling purpose, and level of abstraction – not on the intrinsic nature of the value stream itself.

Other used Terminology

You may also encounter alternative classifications for Value Streams- such as Core and Supportive or Business and Digital – used by organizations like the Value Stream Management Consortium. Each has its pros and cons and may be more appropriate depending on the specific context, purpose, or organizational mindset.⁶

References

1. https://framework.scaledagile.com/ ↩︎
2. https://framework.scaledagile.com/development-value-streams/ ↩︎
3. https://framework.scaledagile.com/operational-value-streams/ ↩︎
4. alue Streams are often organized around domains because modern architectures are structured around bounded contexts, as described in Domain-Driven Design (DDD). A bounded context defines a coherent domain with clear responsibilities and interfaces. Aligning Development Value Streams with these domain boundaries creates structural congruence between architecture and organization, reduces cross-domain dependencies, and enables more autonomous and manageable flow within each domain. ↩︎
5. Nesting is a relationship pattern, not a fixed structural property. It can be applied at different levels of granularity. A value stream viewed in a nested pattern may itself consist of further nested sub–value streams. ↩︎
6. https://www.vsmconsortium.org/vsm-taxonomy#faq-value-stream-categor…-4-2 ↩︎