Metrics That Matter for Delivery

I have seen teams obsess over velocity while missing every deadline. Velocity in isolation tells you almost nothing about delivery health. It tells you how much work the team completed in their own estimation units. That is circular and often misleading.

Here are the metrics I actually track and what each one tells me.

The Four I Watch

Sprint goal completion rate. Not story points completed — whether the sprint goal was met. A team that completes 90% of their points but misses the sprint goal has a prioritization problem. I track this as a binary: goal met or not. Over eight sprints, I want to see 75% or higher.

Cycle time. How long does a piece of work take from "in progress" to "done"? This is the metric that reveals bottlenecks. If average cycle time is increasing, something in the workflow is breaking down — code review delays, QA bottleneck, environment issues. I review cycle time distribution weekly.

Escaped defects. Bugs found in production that should have been caught earlier. This is a quality metric, and it directly measures the effectiveness of your testing and review process. I track the count per sprint and the severity distribution.

Deployment frequency. How often are we releasing to production? Teams that deploy frequently tend to deploy confidently. Teams that batch releases tend to have bigger, riskier deployments with longer rollback times.

What I Do Not Track

I do not track individual developer output. It incentivizes the wrong behavior and destroys team trust. I do not track lines of code. I do not track hours logged. These are vanity metrics that tell you nothing about delivery outcomes.

Making Metrics Useful

Metrics only matter if they drive action. Every metric I track has a threshold that triggers a conversation. Sprint goal completion below 75% means we discuss planning practices. Cycle time above target means we hunt for bottlenecks. The metric is the signal. The conversation is the action.