Behavioural View discovery intermediate

Value Stream Map

Every step from request to delivery with its work time and its wait time, exposing that most of the elapsed time is queueing.

Cost Optimisation Greenfield Build Cloud-Agnostic Cross-Industry CxO Operations & SRE Engineering

flowchart LR
  a["Idea accepted<br/><i>work 2d</i>"]
  w1(["wait 9d<br/>backlog"])
  b["Refinement<br/><i>work 1d</i>"]
  w2(["wait 4d<br/>awaiting design"])
  c["Build<br/><i>work 5d</i>"]
  w3(["wait 3d<br/>awaiting review"])
  d["Code review<br/><i>work 0.5d</i>"]
  w4(["wait 6d<br/>awaiting test env"])
  e["Test<br/><i>work 2d</i>"]
  w5(["wait 11d<br/>awaiting release window"])
  f["Release<br/><i>work 0.5d</i>"]

  a --> w1 --> b --> w2 --> c --> w3 --> d --> w4 --> e --> w5 --> f
  f --> tot["Work 11d &middot; Wait 33d<br/>Lead time 44d &middot; Flow efficiency 25%"]

What it is

The path from request to delivered change, with work time on each step and wait time in between. The ratio of the two is flow efficiency, and it is almost always far worse than anyone expects — twenty five percent in the example, and fifteen is common.

It is a behavioural view of the organisation rather than of the software, and it is the artifact that redirects an optimisation effort from the wrong place.

When you produce it

When delivery feels slow and the proposed remedy is "the developers should code faster". The map usually shows coding is the smallest number on the page, and that the release window and the test environment queue are the constraint.

Who reads it

Executives, who fund the fix. Delivery leads, who own the queues. Engineering, who are usually relieved.

What good looks like

Wait time is measured, not estimated. Ticket timestamps are usually enough.
Both numbers appear for every step, and the totals are stated.
The largest wait is highlighted — that is the only place worth acting first.
Rework loops are shown with their frequency, because a ten percent rework rate can dominate the average.

Common mistakes

Measuring only work time, which is the small half and produces the wrong conclusion.
Averaging across very different work types. Split a bug fix from a feature or the numbers mean nothing.
Fixing a non-bottleneck. Speeding up a step that then waits longer at the next queue changes the total by zero.