Execution and delivery metrics for PMs

Average completed story points over a recent, representative set of sprints. Three to six sprints can be a starting window, but check whether team composition or work changed. Use velocity to inform forecasts, not as a productivity target. Review variation rather than applying a universal 20% predictability cutoff.

Divide remaining points by average velocity for a simple forecast. At 40 points per sprint, a 400-point backlog takes an estimated 10 sprints. A standard deviation of 8 points describes variation in sprint velocity; it does not by itself establish a release-date confidence interval. Use historical delivery scenarios or a suitable simulation to estimate a range.

Lead time runs from request to delivery. Cycle time runs from the chosen work-start point to completion. If an item waits 3 calendar weeks and then takes 4 calendar days to complete, lead time is 25 days and cycle time is 4. Use consistent start and end definitions; both waiting and active work can occur after work starts.

Measure work in progress and time spent in each stage. A persistent queue identifies a place to investigate capacity, dependencies, and blocked work. It does not prove the cause. Test changes such as limiting upstream work or resolving a dependency, then compare flow over time.

For continuous flow, throughput and cycle time are usually more useful than points per sprint. If your team also uses sprints, velocity can support that planning cadence. Choose metrics that match how work is delivered.

DORA measures software delivery throughput and instability. Its current five metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Change lead time runs from a code commit to production; it is not the full time from a customer request to delivery. Source: https://dora.dev/guides/dora-metrics/

Review work in progress, blocked items, dependencies, and rework before asking the team to take on more. WIP limits can help make queues visible and reduce overload, but they do not guarantee a particular cycle-time improvement. Measure whether a change helps your workflow.

Use delivery times and clearly labeled forecast ranges. For example, a historical range of 8 to 14 days is more interpretable when you also state which work items and dates it covers. Use percentile labels only when they come from your data or forecast method, and choose the planning percentile based on the cost of missing the date.