Delivery metrics that don't lie: reading throughput, velocity, and cycle time in the AI age

Every delivery metric can be gamed, and AI makes gaming easier. When an agent can spin up items, close them, and move cards at speed, a dashboard can look busier than ever while the thing customers wait for arrives no sooner. The risk in the AI age is not too little activity. It is mistaking activity for progress at a scale no human ever could.

The metrics worth watching are the ones that resist that. Read them right and they tell you whether value is actually being delivered. Read them lazily and they tell you whether people, or agents, are moving. Here are the four that matter and how to keep them honest.

Throughput: completed work per period, with the reopens removed

Throughput is how much work actually finished in a period. It is the closest thing to a delivery heartbeat, and it has one common failure: counting work as done that later came back.

An item marked complete, then reopened because it was not really finished, should not inflate your throughput. If it does, the number rewards the appearance of finishing over the fact of it, which is exactly the behavior a fast contributor will exploit. The fix is to net out reopened items so the total reflects work that stayed done. In DevStride, get_throughput does this by default, and it reports a trailing average so a single good or bad week does not read as a trend.

Watch the direction more than the absolute. Throughput climbing steadily quarter over quarter is a healthy signal. Throughput that spikes and then gives it back is usually rework wearing the costume of output.

Velocity: what a team completes per cycle

Velocity is throughput scoped to a team and a cycle. It is useful for planning, because it tells you what a given team has actually been able to complete, not what they hoped to. get_velocity gives you that per team.

The honest use of velocity is forecasting, not comparison. Comparing one team's velocity to another's is how the number goes bad, because two teams estimating differently are not on the same scale. Use it to answer "what can this team realistically take on next cycle," and it stays trustworthy. Use it to rank teams and it becomes a target, and targets get gamed.

Cycle time: how long work actually takes

Cycle time measures how long work takes from start to finish. It is the metric your customers feel, because it is the wait. Throughput can look fine while cycle time quietly stretches, which means work is starting and finishing but taking longer to get through, often because too much is in progress at once. get_cycle_metrics surfaces that.

Cycle time is the one to watch when you add AI to a team. If an agent helps you start more work but nothing finishes faster, cycle time will say so plainly while throughput hides it. Falling cycle time is the signal that the speed is real and reaching the customer.

Current progress: done versus in progress versus not started

The last one is a snapshot, not a rate. get_current_progress shows done versus in progress versus not started at any level, from a single team to the whole portfolio. It answers "where are we right now," and it is the antidote to the status meeting, because anyone can see the real picture without someone assembling it by hand.

The reason it can be trusted is structural. When the plan and the work share one model, current progress is not a report someone compiled, it is the state of the system. The number an agent reads is the number on the board.

Why this matters more with AI in the loop

A human team games metrics slowly and visibly. A team with an agent can game them fast and quietly, not out of malice but because the agent optimizes for whatever you measure. Point it at "close more items" and it will, whether or not the work was real. Point it at delivered value, measured by throughput that nets out reopens, velocity used for forecasting, and cycle time the customer feels, and the incentive points the right way.

The goal is not more numbers. It is fewer numbers you can actually believe.

The honest edge

Two caveats worth stating plainly. First, every one of these metrics needs history behind it. A two-week-old workspace has no trend to read, and asking an agent to reason over one will get you confident nonsense. Give it a few cycles before you lean on the numbers.

Second, no metric replaces judgment. These tell you where to look, not what to do. A dip in throughput might be a problem or might be a team paying down real complexity that pays off next quarter. The metric raises the question. A person still answers it.

One principle in the AI-era delivery playbook. For why a connected model is what makes any of these numbers trustworthy, see the green board that lied.