Engineering Velocity vs Throughput: What to Measure (and What to Ignore)

Most engineering leaders measure the wrong things. Story points completed per sprint. Number of tickets closed. Lines of code. These metrics are easy to game, easy to inflate, and largely uncorrelated with whether the team is actually shipping value. The metrics that matter are about flow — how quickly work moves through the system, how often it has to come back, and how predictable the whole thing is.

Cycle time is the headline metric

Cycle time is the wall-clock duration from when a task is started (moved into 'In Progress') to when it is closed. It is the most honest measure of how the team's process actually performs. It captures coding time, code review time, deploy time and verification time as one number. A team with a stable, low cycle time is a healthy team. A team with a high or volatile cycle time has process problems that need investigation.

Track cycle time at the team level (weekly median, weekly p95), not at the individual level. Individual cycle time invites the wrong behaviours; team cycle time invites the right conversations.

Throughput is the volume metric

Throughput — tickets closed per week or per sprint, irrespective of size — is the volume companion to cycle time. Together they tell you whether the team is shipping a steady stream of work. Throughput dropping while cycle time rises is the early warning of a process problem (often: code review bottleneck, or work in progress out of control).

Avoid the trap of weighting by 'story points'. Story points are a planning tool, not a measurement tool. Throughput in raw ticket count is honest; throughput weighted by team-self-assessed effort is not.

Change failure rate and MTTR tell you about quality

The DORA metrics — deployment frequency, lead time for changes, change failure rate, mean time to recovery — are the gold standard for engineering performance, and the last two specifically capture whether speed comes at the cost of quality. A team that ships fast but breaks things weekly is not faster; it is borrowing time from the future. A team that ships fast and recovers fast is genuinely healthy.

Floww surfaces all four DORA metrics as a default dashboard. The point is not to chase a benchmark — it is to make the tradeoffs visible to the team that is making them.

What not to measure

Some metrics produce more harm than insight. Individual lines of code (incentivises bloat). Hours worked (incentivises presenteeism). Number of PRs reviewed (incentivises rubber-stamping). Sprint velocity in story points (incentivises inflation). Anything that turns engineers against each other (stack-ranked anything).

The metrics that work are team metrics, process metrics and outcome metrics. The metrics that hurt are individual metrics, activity metrics and output metrics. The distinction is consequential.

In closing

Measuring engineering well is the difference between a leadership team that knows what is happening and one that is flying blind. Pick the right metrics, instrument them honestly, and let the team improve against them.