Delivery Predictability
Definition
Percentage of committed deliverables shipped on or before the originally-promised date within a measurement window (typically a quarter). Surfaces whether the engineering organization can be trusted to hit commitments the company makes externally — to customers in contracts, to the board in quarterly plans, to GTM teams sequencing launches. Common pitfall: gaming. Teams over-deliver by under-promising (predictability climbs while velocity drops) or move the goalposts (re-baseline mid-quarter so "on-time" stays high). Boards should ask for "predictability against original commitment", not "against current plan", and pair with throughput trends.
Why it matters
Predictability is the contract between engineering and the rest of the business. When it slips, GTM cannot sequence launches, sales cannot promise dates, and the board cannot trust the quarterly plan. Sustained low predictability is a leading indicator of either capacity mismatch, planning hygiene problems, or accumulated technical debt.
How it's calculated
delivery_predictability_pct = (commitments_delivered_on_time / total_commitments) × 100, measured against the originally-promised date (not the most recently re-baselined date). Define "on time" explicitly — within the promised week, sprint, or quarter — and apply consistently. How to interpret it
Industry folk-wisdom, not citation-grade: 70–85% predictability is typical for healthy growth-stage engineering organizations; 90%+ usually means sandbagging (commitments are too soft); below 60% means the planning process is broken or capacity is mismatched. Trend matters more than absolute level — a stable 75% is healthier than a 90% sliding to 70% quarter-over-quarter.
Source
imboard Editorial
Benchmarks
| 25th percentile | Median | 75th percentile |
|---|---|---|
| 55 | 70 | 85 |
Higher is better. Source: imboard Editorial (2026).
Stage relevance
Typically owned by
Related KPIs
Stoplight-plus-narrative status of the strategic product initiatives committed for the current quarter / half — each initiative ideally tagged on-track / at-risk / blocked / shipped, with a one-line explanation. The execution-pulse view that connects strategy intent to delivery reality. Common pitfall: every initiative defaults to "on track" until two weeks before the deadline, then turns red — a board that only sees binary green-or-red status without intermediate "at-risk" signaling is being managed reactively. Pair with `delivery_predictability` to detect this pattern; require at-risk initiatives to surface a mitigation plan, not just a label.
Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.
Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The "available bandwidth for offense" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with `offensive_roadmap_pct` (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together.
Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the "scale runway" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named ("database shard hot-spot binds at ~150K accounts at current growth, ~4 months out"), not just the headline months — a named bottleneck makes the investment decision concrete.
Track these KPIs with your board
I'mBoard helps startup CEOs report the metrics that matter, track resolutions, and run better board meetings.