Execution and delivery metrics for PMs

Story points completed per sprint, averaged over your last 3 to 6 sprints. Don't average more than that, because team composition changes invalidate older numbers. Use the average for forecasting, not as a target. The moment velocity becomes a goal, points inflate and the metric stops working. A good signal is low variance from sprint to sprint. Variance under 20% from your trailing average is generally treated as a predictable team.

Take the points remaining in the release, divide by your trailing average velocity, and add a confidence range based on variance. If you've averaged 40 points with a standard deviation of 8, you're within plus-or-minus two sprints on a 10-sprint backlog. Stakeholders care about ranges, not point estimates. "8 to 12 weeks" is more honest than "10 weeks" and more useful when something slips.

Lead time is from request to delivery. Cycle time is from when work starts to when it ships. Lead time includes the queue. Cycle time doesn't. If a ticket sat in the backlog for 3 weeks, then took 4 days to build, lead time is 25 days and cycle time is 4. Lead time is the metric stakeholders feel. Cycle time is the metric the team can directly improve.

Map the workflow stages and measure how long items sit in each. The stage where items pile up is the bottleneck. Kanban boards make this visible without instrumentation: any column where the WIP keeps maxing out is the constraint. Properly enforced WIP limits surface bottlenecks within a sprint or two. Once you find the constraint, your next move is either to widen it or to slow upstream work so it stops piling up. Adding people elsewhere doesn't help.

Use throughput and cycle time instead. Velocity assumes timeboxed sprints. Kanban runs continuously, so the right metric is items completed per week and how long each one took. Cycle Time and the Cycle/Lead Time Calculator are the better tools here. Velocity in a Kanban context produces theater, not insight.

DORA stands for DevOps Research and Assessment. The four core metrics are deployment frequency, lead time for changes, change failure rate, and time to recover. The 2024 DORA report describes elite-performing teams as deploying multiple times per day, with change lead time under a day, and recovery from failure measured in hours. PMs don't need all four day-to-day, but lead time for changes is the one that maps directly to the rest of execution metrics. If your code lead time is days, your product lead time will never be hours.

Reduce work in progress. Most teams ship slower because too many things are in flight at once, not because the team is slow. Capping WIP forces items to finish before new ones start. Atlassian's Kanban guidance and the Kanban literature both point to the same effect: tighter WIP limits cut cycle time and make blockers visible. Cycle time often drops 30 to 50% when WIP limits get enforced for the first time. The team isn't working harder. They're context-switching less.

Use lead time and a confidence range for forecasts. Skip story points in stakeholder updates. They sound precise and aren't. Saying "we usually finish work like this in 8 to 14 days from when it's requested" tells a stakeholder more than "this is 13 story points." For ranges, give the 50% case and the 90% case. Stakeholders learn quickly that the 90% case is what they should plan around.