Value Stream Mapping (VSM) for Continuous Delivery
Value Stream Mapping (VSM) is a lean management technique used to analyse, design, and optimise the flow of materials and information required to bring a product or service to a customer. In the context of software delivery and continuous deployment, VSM visualises the path of a feature from initial requirement selection (backlog) to running production code.
By mapping out each step of the Software Development Life Cycle (SDLC) and identifying wait states and handoffs, engineering organisations can make data-driven decisions to reduce cycle time and improve delivery velocity.
1. Key Metrics of Value Stream Mapping
To perform a VSM exercise, we track three primary metrics at each stage of the delivery pipeline:
- Lead Time (LT): The total elapsed time from the moment work is selected until it is successfully handed off to the next stage (including wait times in queues).
- Process Time (PT): The active touch time when an engineer is actually performing the work (excluding interruptions, context switching, or waiting in queues).
- Percent Complete and Accurate (%C&A): The percentage of work completed at a stage that the next stage can consume without requiring rework or clarification.
Cumulative System Metrics
Based on the individual stage metrics, we calculate the efficiency of the entire value stream:
- Total Lead Time: Sum of all stage Lead Times.
- Total Process Time: Sum of all stage Process Times.
- Process Efficiency: $\frac{\text{Total Process Time}}{\text{Total Lead Time}} \times 100%$. (A low percentage indicates that features spend most of their lifecycle waiting in queues rather than being developed).
- Rolled First Pass Yield (RFPY): The product of %C&A across all stages: $\text{RFPY} = \prod %C&A_i$. (This represents the probability that a feature traverses the entire pipeline without requiring any rework).
2. Typical Software Value Stream Map
This diagram models a typical software feature delivery flow, showcasing the Lead Time (LT) and Process Time (PT) at each stage, alongside the delay queues between them.
3. Tabular Value Stream Calculation Model
The following table demonstrates a detailed journey of a single feature through our SDLC. It tracks the time parameters and quality yields to identify where waste accumulates.
| Phase | Description / Activity | Lead Time (LT) | Process Time (PT) | Quality (%C&A) | Primary Bottleneck / Delay Cause |
|---|---|---|---|---|---|
| 1. Refinement | Requirement clarification (3 Amigos) | 48 hours | 2 hours | 90% | Waiting for product owner availability |
| 2. Coding | Application development & unit testing | 72 hours | 16 hours | 85% | Context switching due to support issues |
| 3. PR Review | Code review and peer approval | 24 hours | 1 hour | 95% | Code review requests ignored in chat |
| 4. E2E Validation | Automated test run in pipeline | 8 hours | 0.5 hours | 80% | Flaky tests requiring manual retries |
| 5. Deployment | Release promotion to Production | 12 hours | 0.5 hours | 98% | Awaiting manual approval sign-offs |
| TOTALS | 164 hours | 20 hours | RFPY: 56.9% |
Efficiency Calculation
- Total Lead Time: 164 hours (6.8 days)
- Total Process Time: 20 hours (2.5 working days)
- Process Efficiency: $\frac{20}{164} \times 100% = 12.2%$
- Rolled First Pass Yield (RFPY): $0.90 \times 0.85 \times 0.95 \times 0.80 \times 0.98 = 56.9%$
[!NOTE] The Process Efficiency of 12.2% indicates that 87.8% of the delivery timeline is waste (idle time in queues). Optimising the coding phase alone will yield negligible speed gains; the organisation must focus on reducing wait queues (e.g. accelerating PR reviews and automating quality gates).
4. The 7 Wastes of Software Development
Under lean engineering principles, waste is any activity that consumes resources but adds no value to the customer. We map the classic 7 lean wastes directly to SDLC bottlenecks:
1. Overproduction (Extra Features)
- Definition: Building features that are not requested or do not align with current business goals.
- VSM Impact: Inflates coding time and increases the testing surface area.
- Mitigation: Strict enforcement of MVP boundaries and data-driven feedback loops.
2. Waiting (Delays)
- Definition: Stagnation in wait queues (e.g. waiting for PR review, testing environment provisioning, or manual sign-off).
- VSM Impact: Directly inflates Lead Time, reducing Process Efficiency.
- Mitigation: Automating pipeline triggers, using Ephemeral Environments, and eliminating manual approvals.
3. Transport (Handoffs)
- Definition: Moving artifacts or responsibilities between teams (e.g., Dev throwing code to QA, QA passing bugs to Dev).
- VSM Impact: Introduces information loss, defects, and wait states.
- Mitigation: Cross-functional product teams owning quality under the QEaaS Model.
4. Overprocessing (Gold Plating)
- Definition: Performing more work than required (e.g. writing redundant tests, manual regression execution).
- VSM Impact: Consumes active Process Time without increasing quality.
- Mitigation: Optimising the test pyramid, relying on automated unit testing, and deprecating manual UI checks.
5. Inventory (Partially Done Work)
- Definition: Code committed in feature branches but not merged to
main, or features merged but not released to production. - VSM Impact: Creates merge conflicts, stale requirements, and hidden defects.
- Mitigation: Strict Trunk-Based Development, short-lived branches (<24 hours), and feature flag decoupling.
6. Motion (Task Switching)
- Definition: Context switching between unrelated projects, troubleshooting env issues, or searching for documentation.
- VSM Impact: Decreases developer focus and increases errors.
- Mitigation: Enforcing standard local environments, containerisation, and treating documentation as code.
7. Defects (Rework)
- Definition: Bug leakage that requires fix cycles, re-testing, and PR updates.
- VSM Impact: Drastically drops %C&A, forcing the Rolled First Pass Yield (RFPY) down.
- Mitigation: Shifting testing left, running pre-commit quality gates, and automated contract testing.