Milestone delivery predictability

Milestone delivery predictability is the share of committed milestones a team delivers on or before the date it promised. If a team committed to ten milestones in a quarter and delivered eight by their agreed dates, predictability is 80 percent. It measures the reliability of your dates, not your speed. A team that ships slowly but always hits its committed dates is highly predictable, while a fast team that misses half its dates is not.

The metric matters because nearly every other function plans around engineering delivery dates. Sales commits launch timelines to prospects. Marketing books campaigns. Finance forecasts revenue against shipped features. When milestone dates are unreliable, every one of those plans inherits the uncertainty. Predictability is what makes a roadmap a plan rather than a wish.

Predictability is distinct from velocity and from cycle time. Sprint velocity tells you how much a team gets through. Cycle time tells you how long work takes once started. Predictability tells you whether the dates the team gives can be trusted. A team can have high velocity and still be unpredictable if its estimates and commitments are consistently wrong. Measuring predictability surfaces that gap directly.

The base calculation divides the number of milestones delivered on or before their committed date by the total number of committed milestones in the period, expressed as a percentage. If a team committed to twelve milestones and nine landed on time, predictability is (9 / 12) x 100, which is 75 percent. The discipline is in how you define a commitment and a miss.

1. 1

   Capture the committed date

   Record the delivery date at the moment the team commits to it, and freeze it. This committed date is the baseline you measure against. Without a frozen baseline, slipped dates rewrite history and predictability looks artificially high.

2. 2

   Define done

   Agree what counts as delivered. A milestone is met when the work is shipped to the agreed standard, not when it is code complete or sitting in review. A loose definition of done lets near-misses count as hits.

3. 3

   Record the actual delivery date

   Log when each milestone actually shipped. Compare it to the committed date. On or before is a hit. After is a miss, regardless of how small the slip was, because the downstream plan still broke.

4. 4

   Compute the rate

   Divide on-time milestones by total committed milestones for the period and multiply by 100. Track it as a rolling trend and segment it by team and milestone size so the headline rate can be diagnosed.

A single predictability percentage tells you that dates are slipping but not why. Two teams can both sit at 70 percent while one is undone by unclear scope and the other by dependencies it does not control. The fix for each is completely different, so the number only becomes actionable when you break it apart, which is what a metric tree does.

A metric tree decomposes predictability into the stages where commitments break down, then traces each stage to the practice or dependency that causes the slip. This turns a reliability percentage into a diagnosis of where your dates go wrong.

The first level splits the causes of a miss into the points in the delivery lifecycle where dates fail: estimation quality, scope stability, execution flow, and external dependencies. Each then decomposes further. Estimation quality breaks into how well work is sized and how much buffer is built in. Scope stability breaks into mid-flight change requests and unclear requirements. Execution flow breaks into work-in-progress limits and blocked time. Dependencies break into other teams, vendors, and approvals outside the team control. A team missing dates because scope keeps changing has a different problem, owned by a different person, than one missing dates because a vendor is slow.

KPI Tree lets you connect each branch to the person accountable for it. Product owns scope stability and requirement clarity. The delivery lead owns estimation discipline and flow. A programme owner holds the cross-team dependencies. When predictability drops, the push reaches the accountable owner for the branch that is slipping, and the verified impact loop checks whether the change they made, tighter scope control or a dependency unblocked, actually lifted the on-time rate.

Predictability benchmarks depend on how ambitious and uncertain the work is. Research-heavy or early-stage work is inherently less predictable than well-understood delivery. Judge a team against its own trend and the certainty it has promised stakeholders, not against an absolute target.

Read the trend rather than a single quarter. A team climbing from 60 to 80 percent over three quarters is building real discipline, while one that posts a one-off 95 percent by sandbagging its commitments has not. Pair predictability with a measure of throughput so you do not reward a team for promising less and less in order to keep hitting easy dates.

Improving predictability is about making commitments you can keep, then protecting them. The biggest gains come from the branches of the tree that determine whether a date was realistic in the first place: estimation and scope.

The metric tree approach starts by finding the branch responsible for the most missed dates, then assigning the fix to the person who owns that part of the process. If scope churn dominates, that is a product and prioritisation problem. If dependencies dominate, that is a programme management problem. Pushing the team to work faster addresses neither.

KPI Tree connects each branch to the accountable owner and pushes to them when predictability on their branch drops. The verified impact loop then checks whether the change they made actually moved the on-time rate, so the team learns which delivery practices genuinely improve reliability rather than assuming the change worked.

1. 1

   Resetting the baseline when a date slips

   Measuring against a revised date instead of the original commitment makes every team look perfectly predictable. Freeze the committed date at commit time and always measure against it.

2. 2

   Confusing predictability with speed

   A fast team that misses dates is unpredictable, and a steady team that hits them is predictable. Treating the two as the same metric pushes teams to rush rather than to commit accurately.

3. 3

   Letting teams sandbag commitments

   A team can hit every date by promising far less than it can do. Predictability read without a throughput measure rewards under-committing, which quietly slows the business while the dashboard looks healthy.

4. 4

   Allowing a loose definition of done

   If code-complete or in-review counts as delivered, near-misses are recorded as hits and the metric stops reflecting what stakeholders actually received. Hold a strict, shipped-to-standard definition of done.

5. 5

   Tracking the rate without decomposing the misses

   A bare percentage shows dates are slipping but not why. Without a breakdown by cause, every miss looks the same and the team cannot tell a scope problem from a dependency problem from an estimation problem.