Sustainably shortest lead time. Best possible quality and value to people and society.

—House of Lean


Value Streams Abstract

Value Streams are the primary SAFe construct for understanding, organizing, and delivering value. Each value stream is a long-lived series of steps that an Enterprise uses to provide a continuous flow of value to a Customer. The primary role of a SAFe Portfolio is to finance and nurture a set of Solutions development activities (a development value stream) that either deliver end user value directly or support other business (operational) value streams. Identifying and optimizing value streams is a critical skill of the Lean-Agile enterprise.

Organizing around value delivers substantial benefits to the organization, including faster learning, shorter time to market, higher quality, higher productivity, and solutions that are better fit for the intended purpose. In SAFe, organizing around value is accomplished by first understanding the value streams, and then organizing SAFe Agile Release Trains (ARTs) to realize them. Realizing value streams via ARTs is the “art” and science of SAFe.

In addition, value streams lend themselves to systematic analysis and improvement by value stream mapping, which is used to identify and address delays and non-value-added activities, thereby helping to accomplish the shortest sustainable lead time.


Lean and Agile methods both focus intensely on continuous value delivery, whereby value is achieved only when the end user, Customer, or internal business process receives the business benefit of some new Solution or Capability. In Lean, identifying and understanding the various flows of value is the most critical step—indeed, the starting point—for improving overall Enterprise performance. After all, if the enterprise doesn’t have a clear picture of what it delivers and how it delivers it, how could it possibly improve?

This brief background gives SAFe its primary impetus in organizing development Portfolios around flows of value called Value Streams.  

A value stream is a long-lived series of steps used to deliver value, from concept or customer order to delivery of a tangible result for the Customer.

Figure 1 illustrates the anatomy of a value stream.

Figure 1. Anatomy of a value stream
Figure 1. Anatomy of a value stream

The flow of value is triggered by some important event, perhaps a Customer purchase order or new Feature request. It ends when some value has been delivered—a shipment, customer purchase, or solution deployment. The steps in the middle are the activities the enterprise uses to accomplish this feat. A value stream contains the people who do the work, the systems they develop or operate, and the flow of information and materials. The time from the trigger to the value delivery is the lead time. Shortening the lead time shortens the time to market. That is the focus.

Types of Value Streams

In the context of SAFe, systems builders must be aware that there are often two types of value streams present in the enterprise. Operational value streams show the steps used to provide goods or services to a customer, be they internal or external [2]. This is how the company makes its money. Development value streams show the steps used to develop new products, systems, or services capabilities. Sometimes these are the same, as when a solution provider develops a product for sale and feeds distribution directly (example: a small SaaS company). In that case there is only one value stream, as development and operations are the same.

However, particularly in the context of the large IT shop, understanding both types of value streams is critical, as the development value stream feeds the operational value stream, as is illustrated in Figure 2.

Figure 2. Development value streams build the systems that operational value systems use to deliver value
Figure 2. Development value streams build the systems that operational value streams use to deliver value

While the primary purpose of SAFe is providing guidance for the people who build the systems, Lean systems builders first understand the ultimate flow of value so that they can build and optimize systems to accelerate the end result. To this end, identifying value streams is one of the first steps in implementing SAFe. Further, many of the critical requirements for the development value streams, including not just functionality but also system and enterprise architecture, are driven directly by the operational value streams.

Identifying Value Streams

For some organizations, identifying value streams is a simple task. Many are simply the products, services, or solutions they develop and sell. As the enterprise gets larger, however, the task becomes more complicated. Value flows through various applications and services and across many parts of the distributed organization, to many internal and external Customers of many different types. In the larger IT shop, for example, value may move across multiple departments and organizations and across many deployed systems. In such cases, finding the value stream is an important analytical and business context-based activity that provides the most basic foundation for the Lean-Agile transformation.

Questions to Identify Value Streams

Understanding the actual flow of value in an enterprise is a challenge that can only be addressed in the specific business context. A series of questions, such as those in Table 1, can help discover the value streams.

General questions What are the larger software, system, or solution-based objectives that differentiate the business in the market?
How do the external Customers describe or perceive the flow of value they receive?
What current initiatives have a significant number of devs and testers working together now?
Questions for the independent software vendor What products, systems, services, applications, or solutions does the enterprise sell?
Questions for builders of embedded and cyber-physical systems What products and systems does the enterprise sell? What are the larger subsystems or components? What key system operational capabilities are being enabled?
What critical Nonfunctional Requirements are being implemented or enhanced?
Questions for IT What key business processes are enabled?
What internal departments are supported?
What internal or external Customers do those departments serve? How do those departments describe the value they receive from IT?
What key process, cost, KPI, or business improvement initiatives are targeted?

Table 1. Some questions to help identify value streams in an enterprise

Value Stream Definition Template

Once identified, each value stream can be further characterized for more complete understanding. Table 2 provides a template, along with an operational value stream example.

Name Customer order
Description Provides Customers with a fast, consistent ordering experience from mobile or web
Customer(s) Small- to medium-size business
Triggers New customer order or order update
Inputs New order detail (with Customer information)
Outputs Shipment request to shipping, billing information to finance
Includes Internal customer-order work flows and personnel, SAP order management, help desk, mobile and web order entry applications

Table 2. Value stream definition template with an operational value stream example

Development Value Streams Cross Boundaries

Once the value streams are identified, the next step is to start to understand how to form Agile Release Trains to realize them. The ARTs contain all the people and other assets needed to enhance the flow of value. First, the analyst must understand where in the organization that value is created, because that is where the people, processes, and systems are. When doing so, it becomes obvious that development value streams cross many boundaries. Enterprises are organized the way they are for many reasons: history, functional convenience, efficiency of centralization, acquisitions, geography, and more. As a result, it’s quite possible that no one really understands the complete series of events necessary to continually develop and enhance the systems that help deliver the value. Further, attempts to improve tend to focus on functional, local improvements, the result of which may be optimization of one function or step but suboptimization of the end-to-end flow.

It is the long-lived nature of a value stream that triggers different thinking in the Lean organization. To address this, enterprises Apply Systems Thinking and come to understand how various parts of the system need to work together to accomplish improved flow. Typically, larger organizations are organized functionally; in addition, people are distributed in multiple geographies and multiple countries. But value moves across these boundaries, as Figure 3 illustrates.

Figure 3. Value flows across functional, organizational, and geographic boundaries
Figure 3. Value flows across functional, organizational, and geographic boundaries

Budgeting for Development Value Streams

Identifying the value streams and understanding the flow through the organization is an important step in improving value delivery. It also unlocks the opportunity to implement Lean-Agile budgeting, which can substantially reduce overhead and friction and further accelerate flow.

In support of this, each portfolio in SAFe contains a set of development value streams, each of which has its own budget. Program Portfolio Management helps manage the budget for each train in accordance with Lean-Agile budgeting principles. Over time, budgets for each value stream are adjusted as necessary, based on changing business conditions. This is further described in the Budget article. Figure 4 shows the independent budgets for different development value streams.

Figure 4. Each development value stream is allocated its own budget
Figure 4. Each development value stream is allocated its own budget

Value Stream KPIs

A Lean–Agile budgeting process can substantially simplify financial governance, empower decentralized decision-making, and increase the flow of value through the enterprise. It’s a bold move to go from funding projects to allocating budgets to value streams. Naturally, this new approach raises the question, how does the enterprise know it’s achieving an appropriate return for that substantial investment?

To that end, each value stream defines a set of criteria, or Key Performance Indicators (KPIs), which can be used to evaluate the ongoing investment. The definition of the KPIs will be based on the type of value stream under consideration, for example:

  • Some value streams produce revenue, or end user value directly, in which case ROI may be an appropriate measure. Other metrics such as market share, solution usage, and others may provide additional insight.
  • Other value streams, or elements of a value stream, are creating emergent new offerings. In this case, potential ROI is a lagging economic measure. Instead using non-financial, innovation accounting KPIs to get fast feedback may be a better choice.
  • Some development value streams are simply cost centers that serve internal operational value streams and are not independently monetized. In this case, measures such as internal customer satisfaction/net promoter score, team agility/ART self-assessment, feature cycle time, etc., may be relevant.
  • In the largest scale, a value stream may establish an even broader set of measures, such as those represented by the sample Lean-Agile portfolio metrics.

Realizing Development Value Streams with Agile Release Trains

Once the flow of value—and the location of the people and systems that deliver that value—is understood, the enterprise can start to consider how to apply Agile Release Trains to enhance the flow. ARTs are virtual organizations, teams of Agile Teams, that are organized for the explicit purpose of working across boundaries to accelerate delivery. The Agile Release Train article describes the nature and purpose of ARTs. One significant conclusion is that ARTs work most efficiently when they are composed of a maximum of 100 – 150 people. Given that constraint, there are three possible value-stream-to-ART organizational outcomes:

  1. Multiple value streams can be realized by a single ART
  2. There is one value stream, and it can be realized by a single ART
  3. The value stream is large and requires multiple ARTs

An example of each is provided in the sections below.

Multiple Value Stream ART

Consider the case of a small company. Its primary value streams are a website, which is made available to the public for free, and courseware it sells to monetize the business. The courseware is triggered by new content developed and posted to the website. At the time of the example, the business is able to realize its vision with fewer than 50 people in total. In this case, while there are two fairly different value streams, they can be accomplished with a single ART, as is illustrated in Figure 5.

Figure 5. Small, independent software vendor with two value streams and a single ART
Figure 5. Small, independent software vendor with two value streams and a single ART

The top value stream is triggered by new content knowledge, which manifests itself in an updated website and new courseware.

Note: In the larger enterprise this is not the typical case. And even in this case, the company could have supported this with two small ARTs, but then they would have created cross-ART dependencies that would have had to be managed outside the basic ART planning and governance process. Moreover, the company found that reasoning the flow of value in each value stream gave them the insights they needed for accurate delivery. Therefore combining them into one value stream, “framework and courseware,” didn’t seem helpful. Another example of this model is a much larger company that shipped more than 100 high-tech products; they employed about 600 people in development. In this case they organized their ARTs around sets of products, grouped by those that had the greatest commonalities and dependencies. However, each product still delivered its individual end-user value and was budgeted appropriately.

Single Value Stream ARTs

The second example is a medium-size manufacturer who builds automated guided vehicles for multiple marketplaces. One significant market is the amusement parks industry (see the Baja Adventure Ride Example). They have fewer than 200 people on staff, but they are reliant on a Supplier for the track system. In this case, they have two value streams: One is the vehicle and the Supplier-provided track, and the other is the ride management system. Each of these two value streams is realized by a single ART. The ride management system is considered a separate value stream, since it operates under a separate divisional budget, and that group sells variants of that system to other industrial applications as well. This is illustrated in Figure 6.

Figure 6. Medium-size manufacturer with value streams, two release trains, and a Supplier
Figure 6. Medium-size manufacturer with value streams, two release trains,
and a Supplier

Each new system is fairly custom, so the value streams are triggered by an order for a new adventure ride. In turn, that triggers an order to the rail supplier.

Multiple-ART Value Stream

The third example is a “Big Data” IT shop with more than 900 people in development and deployment, and hundreds more in operations. They produce mapping data and algorithms for vehicles and mobile devices. They consider themselves a single value stream but organize development around six ARTs, as shown in Figure 7.

Figure 7. Big Data IT shop with a single value stream organized into six ARTs
Figure 7. Big Data IT shop with a single value stream organized
into six ARTs

In this case, while the enterprise value stream includes all the operations people involved in preparing, editing, normalizing, and mastering the data, the ARTs consist only of the development teams and supporting roles.

Coordinating Agile Release Trains within Value Streams

Figure 7 raises an interesting question. Assuming that there are some dependencies among the ARTs, how does the enterprise coordinate these activities to create a single, holistic solution set? This can require an extensive degree of cooperation; a common Value Stream Backlog; implementation of new, crosscutting capabilities; additional system integration; additional roles and responsibilities; special considerations for Pre-, Post-, and PI Planning activities; different degrees and types of DevOps support; and even more. This is one of the primary challenges of the larger Lean-Agile enterprise.

Fortunately, coordinating multiple Agile Release Trains within a value stream is the entire subject of the Value Stream Level article.

Coordinating Value Streams within a Portfolio

Of course, many significant portfolios contain multiple value streams. While, by design, they should be as independent as possible, there is likely to be some nominal coordination required to ensure that the enterprise moves forward with each value stream in lockstep with the enterprise objectives. This is the topic of the Coordination article.

Reducing Time to Market with Value Stream Mapping

Finally, there is another significant benefit to identifying the value streams and organizing release trains around them. Each value stream provides an identifiable and measurable flow of value to a Customer. As such, it can be systematically improved to increase delivery velocity and quality. For example, what if the ride management system value stream/ART of Figure 6 was always the critical path, and even when the vehicle was ready for shipment the ride management software was not? That would be a high Cost of Delay!

In this case, the ride management ART would apply value stream mapping [3] to identify the steps and flow through the system, and they might describe a flow such as that illustrated in Figure 8.

Figure 8. Ride management system value stream mapping example
Figure 8. Ride management system value stream mapping example

The teams would quickly see that the amount of value-added touch time is only a small portion of the overall time it takes to deliver the end result. After all, it only took them 11 hours of work to create the new feature. And yet it couldn’t be delivered for seven weeks. The majority of the time is spent in handoffs and delays. They have been working hard, and apparently efficiently from the touch time, yet the overall flow through the system could not meet the demand. Coding and testing faster won’t help. Rather, the teams must take the systems view and focus on the delays.

Reducing delays in the value stream is always the fastest way to reduce time to market.

Learn More

[1] Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[2] Martin, Karen, and Mike Osterling. Value Stream Mapping. McGraw Hill, 2014.

[3] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2007.

Last update: 4 April 2016