# Flow Over Velocity

Use WIP, lead time, cycle time, and throughput to discuss flow without turning velocity into a quota.

Duration: 9 min

Busyness is not flow. Follow work from request to delivery and use four plain measures to identify where value is waiting.

## fmap-m4-l1-v1

The approved narration and storyboard are present in the source pack. Final media and caption review remain outstanding.

## fmap-m4-l1-digest

### The vocabulary of flow

Flow is the smooth movement of value from idea to done. A fully occupied team can still have poor flow if work waits in queues, changes hands repeatedly, or remains started but unfinished.

Four measures make the system discussable:

- **Work in progress (WIP):** items started but not finished now.
- **Lead time:** request to delivery—the customer's clock, including waiting.
- **Cycle time:** started to finished—the team's working clock.
- **Throughput:** items finished per period.

Lead time is usually longer than cycle time because requests wait before active work begins. That gap is a queue. Reducing it can improve the customer's experience without asking anyone to work faster.

Velocity is a local planning aid, not a productivity score. Story points are team-specific and estimates are not delivered value. Comparing velocity across teams or turning it into a target invites gaming and weakens the measure.

Good flow questions are concrete: how much has been started, where is it waiting, how long does a request experience, and how frequently do useful items finish? The goal is not motion everywhere. It is finishing value predictably.