What is value stream mapping?

Originally developed in manufacturing, VSM has since become a standard tool in software delivery for diagnosing where work slows down before it reaches the end user. The result is always two diagrams: a current-state map showing how work flows today, and a future-state map showing how it should flow after improvements.

VSM is a diagnostic tool, not a monitoring dashboard. Teams run it periodically to take stock of the current state, design a better one, and then track whether delivery metrics move in the right direction.

Most engineering teams track progress through sprint velocity, cycle time, or deployment frequency, but none of these metrics reveal where work actually stalls. VSM fills that gap by making wait time visible at each stage of the delivery pipeline.

Research on flow metrics consistently shows that most software teams operate at 15-25% flow efficiency — meaning 75-85% of the time a ticket spends in the system, no one is actively working on it. Without a value stream map, those delays stay invisible, buried inside sprint summaries. For engineering leaders, this matters because fixing the wrong constraint produces no meaningful change in delivery speed — VSM points to the right place before any effort is spent.

In software delivery, a value stream typically runs from the moment a feature request is accepted to the moment it is live in production.

A standard software value stream includes stages such as backlog refinement, development, code review, QA, staging, and deployment. For each stage, a VSM records three numbers: process time, lead time, and percent complete and accurate (%CA) — a measure of how often work passes through without being sent back. The ratio of process time to total lead time reveals flow efficiency.

What VSM shows that sprint metrics miss: a two-week sprint can hide the fact that the average PR sits unreviewed for three days, not because reviewers are unavailable, but because there's no queue limit and five PRs land on the same afternoon. Or that the QA stage keeps receiving tickets with incomplete descriptions.

Getting the numbers right requires pulling data from Jira, GitHub, GitLab, and CI pipelines — rather than relying on estimates.

Process mapping and value stream mapping are both visual workflow tools, but they answer different questions and operate at different levels of detail. The table below breaks down these differences across five dimensions:

In short, process mapping clarifies who does what and in what order. VSM builds on that foundation by attaching time data to each step, which is what makes it actionable for delivery improvement. Many teams start with a process map and add timing data to turn it into a value stream map.

That distinction matters when deciding where to begin. If a team does not yet have a shared picture of how work flows, process mapping comes first. If the picture exists but delivery is still slow, VSM is the tool that explains why.

VSM produces useful output only when it is grounded in real delivery data, not workshop estimates. A typical agile value stream mapping exercise follows these steps:

1. Define the value stream scope. Choose a specific flow — for example, from a Jira ticket moving to "In Progress" to the same ticket reaching "Done in production."
2. Identify every stage in the current flow. Walk through the actual process, not the documented one. Stages that are skipped or merged in practice will not appear in official documentation.
3. Collect time data for each stage. Pull lead time and process time from project management and version control tools. For %CA, look at how often work is sent back — rejected PRs, reopened tickets, failed deployments.
4. Map the current state. Plot each stage with its time data. The gap between total lead time and total process time is wait time.
5. Identify the biggest constraints. Focus on stages with high wait time or low %CA. Code review queue depth and QA handoffs usually account for the most wait time — not because those stages are slow, but because work piles up waiting to enter them.
6. Design the future-state map. Agree on a target flow and the specific changes needed — reducing review queue depth, automating a test stage, and clarifying the definition of done.

In agile teams, this process typically runs between major planning cycles rather than inside a sprint — and getting the data manually, correlating ticket timestamps, PR timelines, and deployment logs, is where the work starts to feel heavier than the insight it returns.

Accurate value stream mapping in software delivery depends on data that is rarely in one place: lead time, process time, and wait time sit across task trackers like Jira, repositories like GitHub or GitLab, CI pipelines, and Slack threads that rarely talk to each other. Enji connects these sources into a single view, so teams can measure their current-state value stream without manual data assembly.

• PM Agent pulls data together from worklogs, code metrics, and task trackers on demand. Teams can ask directly where bottlenecks are and which tasks are stalled — which is especially useful when building the future-state map.
• Team Code Metrics cover the delivery stage with the granularity VSM requires: Cycle Time shows how long work takes to move from start to done, Work in Progress tracks queue depth, and PR review time surfaces wait time between writing and merging code.
• Worklogs show actual hours by role and stage against planned estimates. When a stage consistently runs over, it shows up in the data before it shows up as a missed deadline.
• Project Margins translates VSM findings into business language. When the current-state map reveals a bottleneck that inflates lead time, Project Margins shows what that waste costs — turning a flow problem into a budget conversation that leadership can act on.