Flow Over Velocity

Two teams, same company. Team A is always busy — every person loaded, every calendar full, a dozen things in motion at any moment. Team B looks almost relaxed, and yet somehow things keep leaving Team B: finished, shipped, done. Now the question your instincts will answer wrong: which team is more productive? By the end of this module you'll not only know it's Team B — you'll be able to prove it with arithmetic.

This video gives you the vocabulary of flow: four measurements that describe how work actually moves. You'll be able to define WIP, lead time, cycle time, and throughput — and explain why modern teams watch these instead of the metric you've probably heard most about, velocity.

Flow is the smooth movement of value from idea to done. Not how hard people work — how smoothly work moves. That shift of attention, from the workers to the work, is the whole trick of this module. Busy people can coexist with completely stuck work; in most organizations, they do.

Our running example: a customer-support improvement team. Requests come in — fix the help articles, add a returns form, simplify the password reset. The team works on them. Improvements ship. Four numbers describe everything that matters about that pipeline.

Number one: WIP — work in progress. How many items are started but not finished, right now? Count them; that's it. Our support team has eleven improvements "in progress." Remember that number; it's about to become the villain of the module.

Number two: lead time. The clock that starts when a request arrives and stops when it's delivered. A customer asked for the returns form on the first of the month; it went live on the twenty-ninth. Lead time: twenty-eight days. Crucially, this is the customer's clock — it includes every day the request sat waiting in a queue, untouched. The customer doesn't care that you were busy elsewhere. They experience the whole wait.

Number three: cycle time. The clock that starts when someone actually begins the work and stops when it's finished. The returns form took four working days once someone picked it up. Cycle time: four days. This is the team's clock — the part they directly control.

Sit with that gap for a second: twenty-eight days experienced, four days worked. Twenty-four days of pure waiting. There's a name for the ratio — flow efficiency — and here is the industry's dirty secret: for most teams, most of an item's life is spent waiting, not being worked on. The enemy of speed is rarely slow work. It's the queue.

Number four: throughput. How many items get finished per period. Our team completes about three improvements a week. Not started — finished. Throughput counts only what crosses the line.

Now, velocity — the famous one. In Scrum, teams often estimate items in points and track how many points they complete per Sprint. That's velocity, and used properly it's a modest, useful thing: a planning aid. It helps a team forecast what fits in its next Sprint. That's the whole job.

But velocity has three properties that make it dangerous in the wrong hands. It's team-local: points aren't a unit, they're a team's private slang, so comparing velocities across teams is comparing poems by word count. It's gameable: inflate the estimates and velocity "rises" while nothing changes. And it measures motion, not arrival: a team can post magnificent velocity while customers wait forever, because velocity doesn't know what a queue is.

So hold the modern stance: velocity is a guide, never a quota. The moment a manager sets a velocity target, the number stops describing reality and starts performing for an audience — remember the feature factory from Module 3? A velocity quota is its dashboard. Lesson 5 of this module has a name for the whole genre.

Flow metrics resist those failures. Lead time is in days — real, comparable, ungameable days that a customer actually lived through. Throughput counts finished things. You can't inflate "done."

You might think a fully busy team is a productive team — utilization is what we've all been trained to admire. That's understandable: busy looks like output. Actually, the four metrics you just learned describe the work, and the work can be stuck while everyone is magnificently busy — eleven items in progress, twenty-four days of queue inside every delivery. High utilization with high WIP usually means work waiting inside the team. Team A from our opening was busy. Team B had flow. The next lesson shows you the sixty-year-old arithmetic that explains exactly why — and it will change how you run your own to-do list.

Three things to keep. One: flow means watching the work move, not the workers sweat — WIP is what's started, lead time is the customer's clock, cycle time is the team's clock, throughput is what finishes. Two: most of lead time is usually waiting — the queue is the enemy. Three: velocity is a team-local planning guide — a guide, never a quota, and never a comparison.

Eleven items in progress. Twenty-eight-day waits. Four days of actual work. These numbers aren't unrelated — they're bound together by one short equation, older than software, that also runs your coffee shop. Next.