• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Practice : Value Stream Mapping

Purpose and Strategic Importance

Value Stream Mapping (VSM) helps teams visualise and optimise the flow of work from idea to customer value. It reveals delays, handoffs, rework, and bottlenecks—empowering teams to reduce waste and improve delivery speed, quality, and outcomes.

VSM is a foundational Lean practice that shifts the focus from outputs to flow efficiency and systemic improvement. It supports better collaboration between engineering, product, and operations by making work visible and actionable.


Description of the Practice

  • A value stream is the end-to-end flow of work required to deliver value to a customer—often spanning discovery, design, development, test, deploy, and feedback.
  • Mapping the stream visualises each step, including queues, delays, ownership, and systems involved.
  • The map includes data: time-in-step, wait time, WIP, failure rates, and delivery cadence.
  • The goal is to identify flow constraints, reduce lead time, and increase throughput—without compromising quality or sustainability.

How to Practise It (Playbook)

1. Getting Started

  • Choose a product, service, or value delivery slice to map (e.g. “from idea to production”).
  • Gather cross-functional team members: product, design, engineering, QA, platform.
  • Use a virtual or physical whiteboard to chart key steps and actors in the workflow.
  • For each step, note:
    • What happens?
    • Who’s involved?
    • How long does it take (active vs. waiting)?
    • Where are the handoffs or blockers?

2. Scaling and Maturing

  • Include supporting systems (e.g. CI/CD tools, approval processes, ticketing) and cross-team dependencies.
  • Layer in metrics (e.g. average lead time, failure rate, cycle time, WIP).
  • Identify and prioritise improvement opportunities—technical or organisational.
  • Revisit the map regularly (e.g. quarterly or post-retro) as part of a continuous improvement loop.
  • Use maps to justify changes to architecture, tooling, or team structures.

3. Team Behaviours to Encourage

  • Be curious—not critical. Focus on the system, not individual performance.
  • Make work visible—even the messy parts.
  • Treat improvement opportunities as shared, not siloed by function.
  • Reframe blockers as design flaws to be fixed—not just things to “work around.”
  • Use the map to connect technical friction with business impact.

4. Watch Out For…

  • Mapping only the ideal flow and ignoring what really happens.
  • Focusing on speed without considering sustainability or quality.
  • Overcomplicating the map—keep it useful, not perfect.
  • Creating the map in isolation without input from delivery teams.
  • Treating the output as static—VSM should evolve as the team and system evolve.

5. Signals of Success

  • Teams know where their bottlenecks are—and are actively addressing them.
  • Improvements in cycle time, flow efficiency, and delivery predictability.
  • Better alignment between engineering, product, and platform on shared pain points.
  • Maps are referenced during planning, retros, and strategy discussions.
  • Work flows with less friction—delivering more value, sooner.
Associated Standards
  • Teams track time-in-status across their delivery flow
  • Developer workflows are fast and frictionless
  • Delivery pace is sustainable and protects team wellbeing
  • Systems are architected to minimise the cost of change
Associated Measures
  • Cycle Time

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering