Delivery & Flow Metrics

Long before I ever ran a product team, I drove a pallet jack around a massive warehouse, the distribution center for one of the biggest retailers on the planet. The pace of that place has stuck with me ever since. Trucks emptied, pallets landed, boxes rolled out the other side, and nothing sat still long enough to collect dust. Whenever I think about efficiency in business operations, I still go back to that building.

After two years there, I moved and found a job at a competitor. Same industry, same job, literally the same work I had been doing before. That building moved half as many boxes in a day with twice as many people inside it.

Do the math on that one for a second. Per person, the first building was moving four times the boxes of the second one, and the two of them were doing identical work. Flow isn't an abstraction that lives in a textbook somewhere. The gap between a healthy delivery machine and a sick one is enormous, and once you've stood inside both of them, you can feel the difference.

This page is about the numbers that tell you which building you're standing in.

Let's start with the vocabulary, because the delivery section later in this playbook is going to throw these words at you at speed and won't stop to define a single one of them.

• A sprint is the fixed window a team plans its work into and then works inside of, and for most teams that window is one or two weeks.
• A story is a small piece of work that a user can actually see once it's finished.
• A task is one of the small, concrete steps a story breaks into, usually one engineer's piece of the work.
• A story point is a rough size the team agrees to put on a story, where a 1 is small and a 5 is hairy. They're sizes, not hours.
• Velocity is how many of those points your team actually finishes in a sprint.
• Throughput is how many items you finish inside a window of time, which is the same idea as boxes per day back in the warehouse.
• Work in progress is how many items your team has open at the same moment.
• Cycle time is how long a single item takes to travel from started to done.
• An epic is a big committed chunk of work made up of a lot of smaller pieces, and progress per epic is how much of that chunk is actually finished.

Now run that whole list back through the distinction from the last page. KPIs, key performance indicators, track business objectives, and metrics track processes. Every single number on that list is tracking a process, which makes every one of them a metric and not one of them a KPI.

That sorting decides what you're allowed to do with each of these numbers. A flow metric can diagnose your machine, and it can make the work of delivery visible. What it can never do is tell you that you're winning, because you can hit every sprint number you set and still build entirely the wrong thing. I've put it this way before. Build in two-week chunks without ever putting working software in front of a customer, and 18 months later you deliver 1,402 "perfect" features and find out the customers only ever wanted 2 of them. The number's invented. The failure mode behind it isn't.

So the flow numbers aren't there for the scoreboard. They're there for the machine.

Story points are a conversation, not a stopwatch

Story points are relative on purpose. The point of the system was never that half a point should equal two hours of somebody's afternoon. The point is that everyone sizes the work together and then uses those numbers to have a conversation, because the conversation is the thing that unearths all the complexity nobody at the table was thinking about yet.

When two engineers size the same story far apart, you haven't found a math error that somebody needs to go correct. You've found hidden information. One of them knows about a dependency, a fragile service, or a half-finished migration that the other one doesn't. Ex: one engineer has worked inside that fragile service before and the other never has, so the two of them price the same story completely differently. The number's only job in that moment was to drag that knowledge into the room where everyone could see it.

Which is also why a detailed debate about half a point versus a full point is a waste of everyone's morning. That level of precision is too low to help anybody. The system is deliberately fuzzy, and arguing precision back into it kills the one thing it was ever built to do.

There's one rule I hold hard here, and it's that you never convert points into hours. The moment points turn into a clock, people stop talking to each other and start defending themselves, and you've lost the conversation the whole system exists to create. Don't let points score an individual either. Points belong to the conversation and to the plan, and they have no business anywhere near somebody's performance review.

Velocity is for planning, nothing else

Say your team has five people on it, and you suspect that team can get through about 50 points of work in a sprint. It's a planning guess about the team as a whole, and it isn't a quota for any one person on it. So you plan work into the sprint until you're somewhere close to 50 points. One sprint comes in at 48, and the next one comes in at 52. As you keep building, you keep track of how many points the team actually finishes each sprint, and you plan the next one against that history.

Keep doing that sprint after sprint and something valuable starts to happen, which is that the team gets better at planning. Not faster. Better at knowing what it can honestly promise.

That matters a lot more than it sounds like it does. There is no greater disappointment in the corporate world than not delivering something on time, and I don't think that's an exaggeration. A team that knows its own capacity makes promises it can keep, and a team that keeps its promises gets trusted with bigger ones.

But notice what velocity is actually doing in that story. It's an input to a planning meeting, and nothing more than that. It isn't a grade, and the moment somebody turns it into one, the number breaks in your hands. Grade a team on velocity and the estimates inflate, quietly and immediately, and the one honest job the number ever had, which was planning, is gone. Velocity measures motion, not progress. Report it upward as evidence of success and you've built yourself a vanity metric, which was the last page's word for a number that looks like winning and isn't. This one just happens to come with its own chart.

When work gets stuck, shrink the work

The best flow improvement any team of mine ever made didn't involve a chart at all, and it wasn't my idea.

I was running a team of about 26 people at the time, and we kept hitting the same pattern over and over. Someone would pick up a task and say it should take a day or two. Day two passed and it wasn't done. On day three, somebody would finally check in on it and discover that the person had gone down some weird path early on and had been lost the entire time.

Most of the time it was a junior developer, and I don't say that as a knock on junior developers, because the reason they got stuck is almost sympathetic. They don't want to feel like they're bothering a senior person, and rather than show they might be wrong, they put their heads down and try to figure it out alone to prove themselves. Meanwhile everyone around them is busy with their own work, so nobody's looking either. That combination is exactly how a stuck task hides in plain sight.

Three days to find out that one task was stuck. Multiply that across 26 people doing the same thing and you're bleeding weeks you never get back.

One of my tech leads caught it before I did, and she caught it from an angle I wasn't looking at. I was watching the calendar, and she'd been watching the same kind of task struggle in completely different ways depending on who picked it up. Work that one engineer finished in an afternoon could swallow another one for three days, and the work itself was never the thing that changed. So she proposed a rule about size, and then went ahead and put it in place.

The rule was that no task could be designed to be bigger than one day. If you picked up a new task on Monday morning, it should be done by the time you came in on Tuesday. And if it wasn't done, we didn't wait around and we didn't escalate it anywhere. We immediately paired a tech lead or a senior engineer with that developer.

Nobody asked me first, and that's the part of this story I care about more than the rule. She raised it with the team, they agreed it was worth trying, and it was running before it ever reached me. I found out the way everyone else did, by watching the board move differently. People who believe in where you're going don't wait for permission to clear what's standing in the way of it. Everyone on that team knew what we were trying to accomplish, so fixing the thing blocking it was already theirs to decide.

Now, if you're wondering how the guy who just told you never to convert points into hours is suddenly putting a clock on work, that's a fair question. The answer is that points size stories and this rule sizes tasks, and those are different objects. A story is a forecast about a user-visible feature, and humans are famously terrible at forecasts. Daniel Kahneman calls it the planning fallacy, and the bigger the piece of work, the more wildly we underestimate it, which is exactly why story points stay deliberately fuzzy. A task is the opposite case. It's one small, concrete step an engineer takes toward the story, and at that size the planning fallacy has no room to operate (if it does, you sized the task wrong in the beginning). Asking whether one concrete step fits inside a day is an honest question, and asking whether a whole feature fits inside 40 hours never was.

Once that rule took hold, things started to flow. Everything moved quicker and smoother, and stuck work surfaced in a single day instead of three.

What that rule really is, underneath, is cycle time attacked from the input side. Instead of measuring how long items take on the way out and reporting on it afterward, you cap how big an item is allowed to be on the way in, so nothing ever has the room to balloon. You can go buy a dashboard that flags work aging past its estimate, and it would genuinely help. But a dashboard can only flag work once it's outrun the estimate, and inside a two-day estimate on a busy team, stuck work still gets a few quiet days to hide. Make the work small enough and nothing has anywhere to hide in the first place. Shrinking your work items is the most effective flow lever I've ever watched a team pull, and most teams never touch it, because cutting tasks into smaller pieces feels like admin work instead of real engineering.

"But my leadership wants the velocity chart"

I can hear it now. This all sounds nice, Brandon, but my VP asks for the velocity chart every single month, and I'm not winning that fight with a lecture about metrics versus KPIs.

You're right, and you don't win it with a lecture. You win it with a better offer, and what I do is hand leadership two things instead of the chart they asked for.

First, progress that flows up on its own. In my delivery system, tasks are the day-sized pieces we just talked about. Tasks roll up into a story, which is the feature a user can actually see. Stories roll up into an epic, and epics roll into the customer problem they exist to solve in the first place.

Tasks complete, the story gets done, the epic progresses, and the customer problem gets solved. You can track that by story points or by simply counting finished items, and it genuinely doesn't matter which one you choose. What matters is what leadership ends up seeing, which is how far along you are in solving each customer problem, rather than how busy the team looked that month. My job as the product person in that system is to tell leadership how much of a solution to a customer problem has shipped, and engineering owns the per-epic progress underneath it.

Second, a status ritual. When Alan Mulally ran Ford's turnaround, he built the company around a weekly Business Plan Review, where every leader, every week, marked every piece of the plan green, yellow, or red. In the early sessions every chart came up green, and Mulally stopped the meeting on exactly that. Ford was on track to lose billions of dollars that year, so how could every line on the wall be green? Bryce Hoffman's book American Icon tells the whole story, and it's worth your time to read it.

I picked the system up from that book, and I've run a version of it with pretty much every team I've led since. The rules are the part that makes it work. The session is an update and not a debate, so there's no discussion in the room, and anything that genuinely needs discussing gets handled immediately after it ends. Yellow and red are safe to show. No ego. Just data.

A velocity chart answers the question "are we busy." A wall of green, yellow, and red sitting over real customer problems answers a far better one, which is "are we on track, and where exactly do you need help." Most leaders ask for velocity because nobody has ever walked in and offered them anything better than that. So offer them something better.

Point the numbers at the machine

Run this pass on your own team this week, and don't overthink it. It's how you find out which of those two buildings you're standing in.

List out every delivery number your team currently tracks. For each one, name the process decision it feeds, whether that's planning the next sprint, shrinking a task down, or pairing someone onto stuck work. A flow number with no decision attached to it has no reason to exist. That's the same test every number on the last page had to pass. Cut it.

Then check where each of those numbers travels once you've written it down. Anything flowing up to leadership as evidence of success comes off the report, and two things go up in its place. Progress against real customer problems, and an honest green, yellow, or red.

Keep the flow metrics pointed at the machine, and keep the KPIs pointed at the business. Teams that confuse the two ship 1,402 perfect features. Teams that keep them straight ship the 2 that mattered.