The aim of development is, in fact, the creation of profitable operational value streams.
—Allen Ward 
Development Value Streams
A Development Value Stream is the sequence of activities needed to convert a business hypothesis into a digitally-enabled solution that delivers customer value.
As described in Principle #10, Organizing around value, the value stream concept is a critical underpinning of Lean thinking and is fundamental to SAFe. There are two types of value streams described in SAFe.
- Development Value Streams (DVS). This article describes DVS–the sequence of activities to develop and support the solutions used by Operational Value Streams (OVS). One or more Agile Release Trains constitute each DVS.
- Operational Value Streams (OVS). The OVS is the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service.
Systems and software developers, product managers, engineers, scientists, and IT practitioners work primarily in the DVS. External customers use the solutions they create, but many are often internal to the business. These customers (or users) are the people within the enterprise who use those systems to do their job. Others offer products, services, or systems developed by the DVS to external customers.
A SAFe Portfolio defines and governs a set of DVS. Each DVS is committed to building, deploying, and supporting Solutions the enterprise needs to accomplish its business mission (Figure 1).
Lean Budgets and Guardrails support them and empower the workers who make the day-to-day decisions that optimize economic value. This value is measured by Key Performance Indicators (KPIs), Objectives and Key Results (OKRs), and SAFe’s three measurement domains (Outcomes, Flow, and Competency, see Measure and Grow) which are established to evaluate how the value stream is performing in achieving the portfolio’s strategy.
Why Organize People in Development Value Streams?
Simply put, organizing people around the DVS improves workflow, efficiency and accelerates time to market. This is accomplished by optimizing the flow of value to the Customer across divisions and functional departments through suppliers, channels, and the whole system.
Value streams offer many benefits, as they:
- Enable long-lived, stable teams that focus on delivering value
- Help identify and visualize all the work necessary to produce solutions
- Create transparency of delays, bottlenecks, and handoffs
- Support smaller batch sizes of work
- Enable knowledge growth and more continuous learning
- Allow the funding model to shift to value streams from traditional project budgets
Indeed, when you start to understand their worth, it makes you wonder how enterprises ever got along without them. Yes, they were always there, but we didn’t see them. 
Defining Development Value Streams
Value streams contain all the activities, people, systems, and the flow of information and materials needed to deliver value. While OVS vary significantly depending on their purpose, the DVS steps are relatively standard. Figure 2 illustrates the simplified structure of a DVS.
This structure contains the following elements:
- Trigger – the value stream is triggered by a new request, though many new requests are moving through the value stream at the same time.
- Steps – contain the activities needed to define, build, validate, and release new value.
- Bar – the bar between the steps indicates information and materials flowing from one process to the next. It also implies the typical handoffs of information that occur as people in different steps add value to the process.
- Ellipses (…) – indicate the delays between these steps, typically the most significant contributors to long lead times. Decreasing delays is usually the fastest and most efficient way to reduce lead time.
The output of the DVS is a new increment of the solution, the additional value these new features provide.
This example DVS in Figure 2 is an incredibly simplified model of what it takes to create innovative technical solutions in today’s digital enterprise. Still, it serves an important purpose: it illustrates the activities needed to deliver solutions and the time it takes.
The Operational Value Streams article describes how value streams deliver solutions and support the Customer’s needs. Indeed, as Ward notes,  the entire purpose of development value streams is to make operational value streams—and, thereby, the whole enterprise—more profitable and more efficient in delivering value. As that article illustrates, four common OVS value stream patterns—fulfillment, manufacturing, software products, and support— lend themselves to different types of DVS patterns.
1. Fulfillment DVS Pattern
The first pattern (Figure 3) is a consumer loan example. Patterns like this are fairly standard in insurance, banking, financial services, and related industries that offer complex, digitally-enabled products and services to consumers (B2C) and businesses (B2B).
A fulfillment OVS represents the steps to process a customer request, deliver a digitally-enabled product or service, and receive payment. Examples include providing a consumer with an insurance product or fulfilling an eCommerce sales order (Figure 3).
In this case, the product is more virtual than tangible, as the ‘loan product’ is a set of commitments, interfaces, applications, services, contracts, licenses, and other relationships that constitute the consumer product or service.
The Customer interacts at various points throughout their journey. Although critical, customer access points are only the tip of the development iceberg; most of the development happens on internal enterprise-class systems, like those depicted for the commercial banking system.
To build and maintain these systems, multiple development streams may be required. For example, one development value stream supports the front-end loan origination services and credit scoring; another builds the core banking services.
2. Manufacturing DVS Pattern
Figure 4 illustrates a pattern for manufacturing a significant cyber-physical system, in this case, a passenger vehicle. This pattern shows fundamental differences between the development streams that directly support digital solutions and those that support products that must be manufactured before use.
In this case, the delivered value is not the product, but the specifications needed to manufacture and validate it. The focus is on Solution Intent, the repository of design specifications, manufacturing procedures, bills of materials, and so on, required to produce the device.
In this context, teams serve two types of customers:
1. The ultimate Customer is the end-user of the manufactured product (the driver of the vehicle in this case)
2. The manufacturing personnel who use the specifications to build the product (illustrated with the blue ‘shop foreman’ icon).
Of course, the size and the number of DVS vary with the solution’s complexity. In some instances, thousands of people are involved in designing such a system (vehicle, aircraft, satellite, smartphone, and so on). But it’s also the case that many manufactured products can be developed by a single development value stream (drone, webcam, remote control, and so on).
The more complex case pictured above illustrates another common sub-pattern in which some DVS directly support others. In this example, one DVS is devoted to building vehicle designers’ tools needed by another DVS to design, simulate, and validate their products.
Also pictured is a ‘digital twin,’ a replica of the product used to validate design assumptions. This twin is a common Lean-Agile strategy for building significant cyber-physical systems.
3. Software Products DVS Pattern
Many software development and IT practitioners work in the Independent Software Vendor (ISV) industry, where vendors directly produce and market software products. The software products segment includes the largest digital-native companies and hundreds of thousands of enterprises that sell everything from IT services to hospital information systems, desktop software, gaming, and simple mobile apps.
Figure 5 illustrates a pattern for a significant enterprise that develops and supports a substantial software application.
This illustration shows how the largest focus of development effort goes directly into the software solution. The customers (and various customer personas) are users of the system. Hundreds or even thousands of people may be directly involved in developing, deploying, and maintaining such systems.
But the system doesn’t sell itself, answer support calls, or collect revenue. The OVS is responsible for customer acquisition, internal operations, support, and more. As pictured, some software and IT practitioners support and maintain those internal systems. It’s also important to note that customers interact with the company throughout their buyer journey while using the application. As illustrated here, a DVS is devoted to supporting that functionality. It could be distributed to the other development Agile Release Trains (ARTs) for a more stream-aligned end-to-end approach. However, a common approach to the customer experience may warrant a separate development value stream.
4. Supporting DVS Pattern
The final type of OVS serves ‘supporting value streams,’ the internal and critical functions, and the people and processes that keep the enterprise running. Common examples include the annual audit process, hiring and onboarding personnel, and many other significant, repeating workflows. Additionally, enterprises engaged in logistics, supply chain, research, data mining, drug discovery, and so on have extensive and critical internal supporting value streams, with activities far earlier than those aimed at the end customer. Many such supporting value streams exist, creating substantial demand for development.
Often, multiple OVS can be supported by one DVS that builds, configures, and supports the systems the OVS needs to function and share standard information.
Figure 6 illustrates an example of a single DVS that supports an ERP system used throughout the enterprise.
In this example, there is only an internal Customer. That’s because, in this case, the DVS supports an OVS internal to the enterprise. The Customers for the DVS are the users, stakeholders, and employees who work in the OVS (indicated by the circled people icon).
Understanding this internal flow of value is as critical as understanding the external Customer. The mindset, methods, and practices of Customer Centricity and Design Thinking apply equally to the teams on this DVS.
Defining Development Value Streams
The four OVS patterns described earlier help define the DVS structure for optimal value delivery. Once initially identified, additional analysis is required to determine the DVS boundaries, people, solutions, and other deliverables. Figure 7 provides a Development Value Stream Canvas, a simple template that can capture and refine the emerging understanding.
Optimizing Development Value Streams
Finally, there is another significant benefit to value stream analysis. Each value stream provides a customer with an identifiable and measurable flow of value. As such, “value stream mapping” [2,4] can be applied to measure and improve delivery velocity and quality systematically.
As teams and ARTs begin adopting DevOps, the learning from the journey is often surprising. Figure 8 illustrates an example of a team doing their first mapping of a typical feature as it moves from definition to production.
The flow metrics for the value stream offer strong evidence that substantial improvement is required. Only 5% of the lead time was value-added activity time. The other 95% was spent waiting! Also, there was significant rework; just 36% of the features made it through the DVS without it being returned to an upstream process.
These results provide ARTs with a good business case to invest in value stream mapping and further automating the Continuous Delivery Pipeline, as shown in Figure 9.
The continuous improvement process enables the DVS to predictably deliver innovation and value in the shortest sustainable lead time with the highest possible quality.
 Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2014.
 Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda, 20th-anniversary edition. 1998-2018. Lean Enterprise Institute.
 Thanks to SAFe Fellow Mark Richards for contributing to the Value Stream Canvas concept.
 Martin, Karen, and Mike Osterling. Value Stream Mapping. McGraw Hill, 2014.
Last update: 14 November 2022