To run SAFe value stream mapping, work in four steps. First, identify your operational value streams. Second, identify the development value streams and Agile Release Trains that build the solutions behind them. Third, map the current state of one development stream, recording process time, wait time, and quality at each block. Fourth, find the longest delay and draw a future state that removes it. A working group can finish a first pass in a single workshop.
The hard part is rarely the drawing. SAFe uses two kinds of value streams, and teams mix them up. They treat every product as its own stream, map their customer’s process instead of their own, or skip identification and go straight to sticky notes. The result is a tidy map that nobody acts on, because it does not show where work actually waits.
This guide walks through each step with a worked example you can adapt. Lean Six Sigma Experts has helped businesses with Lean Six Sigma since 2011.
What SAFe value streams are and why you map them
A value stream is the sequence of activities your organization performs to turn a customer request into delivered value. SAFe value stream mapping draws that sequence with its delays, handoffs, and quality problems, so you can see where flow breaks. SAFe adds one twist to the Lean original: it separates two types of streams.
Two types, two jobs
Operational value streams (OVS) are the activities that deliver a product or service to a customer. Development value streams (DVS) are the activities that develop and support the solutions the OVS depends on.
| Operational value stream | Development value stream | |
|---|---|---|
| Purpose | Deliver a product or service to a customer | Build and support the solutions the OVS uses |
| Steps | Vary by business | Always Define, Build, Validate, Release |
| Who runs it | Business functions | An Agile Release Train (ART) |
| Example | Order to cash for an insurance product | Building and releasing a customer portal |
SAFe puts more weight on the DVS because ARTs are organized around it. The mapping workshop in SAFe usually targets a DVS.
Map the development value stream first, because that is where an Agile Release Train can change flow.
Where Lean and Six Sigma fit
Value stream mapping is a Lean tool. The concept comes from Toyota’s production system, and the term was popularized in the 1990s book The Machine That Changed the World. Six Sigma teams use the same maps to decide which process step to measure and fix, so the answer to "Lean or Six Sigma?" is both. SAFe also separates two activities. Identification is a high-level exercise that names your streams and ARTs. Mapping is the detailed work of measuring flow through one stream. Do identification first.
What you need before you start
- Release Train Engineer, who facilitates
- Product manager, system architect, and a business owner
- People who do the work: developers, testers, operations
- A wall, sticky notes, and markers, or a shared digital whiteboard
- Timestamps from your work tracker, so times are measured and not guessed
Step 1. Identify your operational value streams
Start with the customer trigger and follow the work until the customer receives value. Write the trigger on the left, such as "customer places an order." Write the delivered outcome on the right, such as "customer is using the product and billed correctly."
Pick the closest pattern
SAFe offers four common OVS patterns. Choose the one that matches how you earn revenue.
| Pattern | What it covers | Example |
|---|---|---|
| Fulfillment | Process an order, deliver, get paid | Insurance product, loan |
| Manufacturing | Turn raw materials into a product | Building a car |
| Software products | Offer and support software | SaaS, ERP, mobile apps |
| Supporting | Internal, repeating business activities | Hiring, annual audits |
Sketch five to fifteen blocks
Break the stream into high-level process blocks. Five to fifteen is a good range. Add a block wherever work stops or pauses. A SaaS company might draw: order received, account validated, environment provisioned, customer onboarded, invoice sent, support provided. Do not map detail yet. You only need the shape.
Avoid the two counting mistakes
Smaller organizations tend to find too many streams. Many have one customer-facing OVS and a couple of development streams. Two mistakes cause the inflation. The first is treating each product as its own OVS. A mobile app and a web app are usually variants delivered through the same stream. The second is mapping your customer’s value stream. If you sell ERP software, how your customer runs their business is useful context, but it is not your stream.
If two products share the same trigger and the same delivery steps, they belong to one value stream.
Step 2. Define the development value streams
For each OVS block that depends on software, ask which solution supports it and which team builds it. That solution belongs to a development value stream. A DVS is realized by an ART and always follows the same four stages: Define, Build, Validate, Release.
Link solutions to the operational blocks
Take the SaaS example from Step 1. The blocks rely on four internal solutions: a customer portal, a CRM, a provisioning tool, and a helpdesk system. The customer also uses the product itself. Each of these is built by someone, and those builders form your development streams.
Two kinds of solutions appear here. Some serve internal users who need them to do their jobs. Others serve external customers who buy or use them. Both count, and both need a stream.
Group them into streams and trains
Group solutions that share a team and a delivery pipeline. A plausible result for the example company:
| Development value stream | Solutions built | Supports OVS blocks |
|---|---|---|
| DVS 1: Customer product | The product customers use | Onboarding, support |
| DVS 2: Order and billing systems | CRM, customer portal | Order received, invoice sent |
| DVS 3: Platform operations | Provisioning, helpdesk tools | Provisioning, support provided |
Each DVS gets an ART, or shares one when the teams are small. Pick one stream to map first. Choose the one where customers or executives complain about delay.
A development value stream is not a product list. It is a team and pipeline that delivers a set of solutions.
Step 3. Map the current state of one stream
Map the stream as it runs today, not as the process document says it runs. Gather the group, pick one DVS, and walk the real path of a typical work item from idea to release.
Run the mapping session
- Draw four blocks: Define, Build, Validate, Release. Split any block that hides a pause, such as a security review queue.
- Under each block, record process time, the hours or days people actively work on it.
- Between blocks, record wait time, the days the item sits in a queue.
- Add percent complete and accurate (%C&A), the share of items that arrive from the previous step without needing rework.
- Note the systems used and the roles involved at each block.
Any surface works for the map as long as everyone can edit it live. Use a physical wall for an on-site session, or a shared whiteboard for a remote one. Put the arithmetic in a spreadsheet.
Worked example with numbers
These figures are illustrative. They show how the math works for a typical stream.
| Block | Wait before (days) | Process time (days) | %C&A |
|---|---|---|---|
| Define | 12 | 4 | 70% |
| Build | 5 | 15 | 85% |
| Validate | 20 | 6 | 60% |
| Release | 9 | 1 | 90% |
| Total | 46 | 26 | 32% rolled |
Total lead time is 46 + 26 = 72 days. The activity ratio is process time divided by lead time: 26 ÷ 72 = 36%. Rolled %C&A multiplies the blocks: 0.70 × 0.85 × 0.60 × 0.90 = 32%. Only about one third of the lead time involves real work, and about one in three items passes every step without rework.
Lead time tells you how slow you are, and activity ratio tells you how much of that slowness is waiting.
Step 4. Find the delays and draw the future state
Attack the largest wait first, not the longest task. In the example above, Build takes the most effort at 15 days, but Validate holds the biggest queue: 20 days of waiting plus the lowest quality score at 60%.
Read the map and pick one target
Rank blocks by wait time, then by %C&A. Validate (20 days, 60%) and Define (12 days, 70%) stand out. Ask why work waits in Validate. Typical causes are a shared test environment, manual regression testing, and a late security review. Choose the cause your train can change itself, and name one owner.
Draw the future state and measure it
Redraw the same four blocks with the change applied. Suppose automated regression tests and an early security review cut the Validate wait from 20 days to 5. Release on demand cuts its wait from 9 days to 1. Waits become 12 + 5 + 5 + 1 = 23 days. With process time unchanged at 26 days, lead time falls from 72 to 49 days. Activity ratio rises from 36% to 26 ÷ 49 = 53%.
Then track whether it holds. SAFe flow metrics such as flow time, flow efficiency, and flow load show whether the change worked. Remap after a few program increments, since a one-time map decays. Two other pitfalls are mapping only the happy path and leaving business stakeholders out of the room.
If your group needs to learn the mapping method itself, the Lean Online Training Modules from Lean Six Sigma Experts include value stream mapping alongside the Eight Wastes, 5S, and Kaizen events.
Fix the biggest queue, remeasure, then move to the next one.
Start with one stream
SAFe value stream mapping comes down to a clear order of work. Identify your operational streams, find the development streams and ARTs behind them, map one stream with real times, and redraw it without its biggest delay. Keep the first map small. One stream, four blocks, and honest numbers will teach your group more than a wall-sized diagram of everything.
If you want a second opinion on your streams or help running the workshop, contact Lean Six Sigma Experts. The first conversation can start with a free consultation.