A commerce platform's engineering throughput is high but features take months to reach merchants. Where does value-stream mapping look, and what does it typically find?
Show the full answer Hide the answer
What value-stream mapping measures
The whole path from idea to merchant value, including every wait, not just the engineering steps.
The essential measurement is the ratio of work time to wait time. In most organisations, work time is a small fraction of lead time, which means optimising engineering throughput — the part everyone measures — addresses the minority of the problem.
Where the wait time typically is
1. Before work starts. Ideas sitting in a backlog awaiting prioritisation, specification or a decision nobody owns. This is frequently the largest block and it is invisible in engineering metrics because the clock has not started.
2. Handoffs. Design to engineering, engineering to review, review to QA, QA to release, release to enablement. Each handoff is a queue, and each queue's length is a function of the receiving team's utilisation — which is why fully-utilised specialist teams create long waits everywhere upstream.
3. Batching. Work completed and held for a release train, a marketing moment, or a documentation cycle. Completed-but-unreleased work is finished value not yet delivered, and it is usually not measured at all.
4. Approvals. Architecture review, security review, change advisory. Each is defensible and each is a queue, and their aggregate is frequently weeks.
5. After release. Feature flagged off, gradual rollout, enablement and communication. For a platform serving merchants, the gap between "deployed" and "merchants can use it" is real and frequently unowned.
What it typically finds
The bottleneck is rarely engineering. It is a specialist team with high utilisation acting as a queue for everything, a decision that waits for a monthly forum, or a batching policy that holds finished work.
And the second finding: the process is optimised for utilisation rather than for flow. A team kept fully busy maximises its own efficiency and maximises the queue in front of it. Deliberate slack in the constrained step reduces total lead time even though it lowers that team's utilisation — which is counter-intuitive and is why it is rarely done without the mapping to justify it.
The metrics to adopt
Lead time from commitment to delivery, deployment frequency, work-in-progress limits, and — most diagnostically — the ratio of active work time to elapsed lead time. That last number is what turns a vague sense of slowness into a specific, arguable target.