Dates that can't be trusted have a business cost: planning becomes guesswork, coordination grows, and revenue arrives late. The fix is in the flow of work, not in pushing people harder.
Two numbers define it: the ratio of committed work delivered per period, and how stable your cycle times are. Together they tell the business whether a date from engineering is a plan or a wish.
Predictability is also an economic variable. Unpredictable delivery raises the cost of delay and coordination — margin leaks that never show up in a sprint report.
Plus stable cycle times. A healthy working range for most product teams: 80–90% sustained. 100% every sprint usually means sandbagged commitments.
Almost never because people aren't working hard. The causes are systemic, and they compound:
High work-in-progress means constant context switching and long queues. Each item ages while it waits; cycle times stretch and every date built on them slips.
Cross-team handoffs and reliance on a few senior individuals turn your plan into a queue you don't control. One busy reviewer can silently set the delivery date for the whole team.
Incidents, urgent requests and defects consume capacity that commitments assumed was free. If you don't measure this share, every plan starts oversubscribed.
Optimistic estimates become promises, buffers get negotiated away, and the gap is discovered at the deadline. Forecasting from measured cycle times fixes what better estimating never will.
AI adoption adds a fifth cause when unmanaged: faster generation with slower verification increases variance — more output, less certainty about when it's actually done. That's a guardrails problem, and it lands on predictability first.
A baseline on these four takes one to two weeks from your existing tooling — no new tools required. It's the first thing we establish in the Diagnostic.
| Metric | What it tells you | Warning sign |
|---|---|---|
| Committed vs delivered | Whether commitments can be trusted | Below ~70%, or exactly 100% every sprint |
| Cycle time distribution | How long similar work actually takes | A long tail of items taking 3–5× the median |
| Work in progress | How diluted the team's attention is | More items in flight than people on the team |
| Unplanned work % | How much capacity plans can really count on | Not measured at all — the most common state |
Notice what's not on the list: new ceremonies, a framework migration, or more pressure. Predictability is a flow problem. This is the core of our Delivery & Agile Transformation work — and why it's measured, not facilitated.
No. Velocity measures output volume in points, which can inflate without delivering more value. Predictability is committed vs delivered plus stable cycle times. A team can have rising velocity and falling predictability at the same time.
Sustained 80–90% is a healthy range for most product teams — high enough to plan around, honest enough to leave room for learning. Exactly 100% every sprint usually means sandbagged commitments.
No. Commit to what the data says fits — including the measured share of unplanned work — and treat the rest as stretch. Overcommitting to look ambitious is how trust in dates erodes.
Measured cycle time distributions and throughput. If you know how long similar items took and how many the team finishes per week, you can forecast probabilistically and communicate ranges with confidence levels instead of single points that will be wrong.
With WIP limits and smaller slices, teams usually see cycle times tighten within 2–4 sprints. Trust from the business takes longer — it returns only after several periods of dates that held.
Nicolás Espinosa — Founder, Optimum Agile. Former Director of Product at PikPok and Senior Delivery Manager at Trade Me; postgraduate specialisation in AI Product Management (Duke University). Based in Auckland, working with software companies across New Zealand and Australia on delivery economics and disciplined AI adoption.
Last updated: July 2026
45 minutes with Nicolás. Your leaks, your baseline, and a written 30-day roadmap — yours to keep either way.