Value Stream Mapping

Overview

Value Stream Mapping (VSM) is a lean engineering practice that visualizes every step in the path from a feature idea to production delivery. By measuring the time spent in each stage, teams identify where work waits, where it's blocked, and where process changes will have the most impact.

Koalr's Value Stream page automatically constructs your team's value stream from connected data — no manual timeline-building required.

What the value stream captures

Koalr maps a 6-stage value stream from your GitHub, Jira, and CI/CD data:

Backlog → In Progress → In Review → Merged → Deployed → Verified

Stage	Start event	End event	Data source
Backlog	Issue created	Issue moved to In Progress	Jira / Linear
In Progress	First commit on branch	PR opened	GitHub
In Review	PR opened	PR merged	GitHub
Merged	PR merged	Deployment started	GitHub + CI
Deployed	Deployment started	Deployment succeeded	GitHub / Vercel / Railway
Verified	Deployment succeeded	Incident-free period (48h)	PagerDuty / OpsGenie

Key metrics

Lead time

Total time from issue creation to production deployment. This is the "total" lead time — it includes backlog wait time that DORA's Lead Time for Changes excludes.

Cycle time

Time from first commit to production deployment. This is the DORA definition and excludes backlog wait time.

Flow efficiency

Flow efficiency = active work time / total elapsed time × 100

Active work time = coding time + review time (when someone is actively working on the item). Elapsed time = lead time (including all waiting).

A flow efficiency of 20% means that only 1 in 5 calendar days has active work happening — the rest is waiting. Most teams are at 15–25%. Elite teams achieve 40%+.

Wait ratio per stage

The percentage of total lead time spent waiting vs. working in each stage. The stage with the highest wait ratio is the bottleneck.

Dashboard sections

Value stream funnel

A visual funnel showing how work moves through all 6 stages with median time at each stage. Immediately shows where the largest time gaps are.

Stage timing breakdown

Bar chart comparing median and P75 time in each stage:

• Highlights which stage is the primary bottleneck
• Compares to prior period to show improvement or regression
• Filterable by team and repo

Flow efficiency trend

12-week line chart of flow efficiency. Improving trend means more calendar time is spent doing work and less time waiting.

Issue-level value stream

Click any issue in the table to see its individual value stream timeline:

• A Gantt-style horizontal timeline showing each stage
• Exact timestamps for each transition
• Annotations for blockers, review requests, and CI failures

Bottleneck identification

Koalr automatically identifies which stage is the current bottleneck across your organization's recent work and suggests the highest-leverage action:

• Backlog too long → prioritization or capacity problem
• In Progress too long → WIP accumulation or PR size problem (see WIP Limits, PR Size)
• In Review too long → reviewer pickup time or review depth problem (see Review Queue)
• Merged → Deployed too long → deployment pipeline speed or manual deployment steps
• Verified stage failures → incidents following deployments (see Incidents)

Setting flow efficiency targets

Navigate to Settings → Work Configuration to:

• Set flow efficiency target (default: 30%)
• Configure stage definitions (customize which issue statuses map to which stage)
• Set Verified stage criteria (default: 48 hours without an incident)
• Filter which issue types to include (Stories only, or include Bugs and Tasks)

Interpreting common patterns

Long backlog stage

Items sit in backlog for weeks before being started. Indicates either over-full backlog (too much planned, not enough capacity), unclear prioritization, or dependency blocking.

Long In Progress stage

Items started but PRs not opened for days. Indicates PRs that are too large, scope creep mid-implementation, or developers working without review checkpoints.

Short In Progress, long In Review

PR opened quickly but sits waiting for review. Classic reviewer pickup time problem — see Review Queue for interventions.

Long Merged → Deployed stage

PRs merge but don't deploy for hours or days. Indicates manual deployment triggers, deploy trains, or CI/CD pipeline speed issues.

Relationship to other metrics

• Cycle Time — the In Progress + In Review stages correspond to coding time and review time in the Cycle Time breakdown (Cycle Time)
• DORA Lead Time — DORA Lead Time = In Progress + In Review + Deploy stages combined (DORA Metrics)
• WIP Limits — excessive WIP is the leading cause of long In Progress stage times (WIP Limits)
• Deploy Risk — the Verified stage failure rate correlates with deploy risk scores (Deploy Risk)