You Can't Tell Your CEO When It'll Ship. That's a Choice.

TL;DR: That moment in the exec meeting - "when will it ship?" and you hear yourself invent a date - doesn't have to keep happening. You can't give a date because delivery time is a distribution. You can give a range from your own history, this week, for free: pull the elapsed times of your last 20 shipped items and read off the half-ship-by and most-ship-by points. That answer is honest, it's defensible, and it gets sharper as delivery gets more consistent. Guessing is a choice. Stop making it.

The CEO asks when the feature ships. The room turns to you. And you hear yourself say "end of the quarter, probably," a date assembled from optimism, last night's standup, and the look on your tech lead's face. You'll spend the next six weeks managing the gap between that sentence and reality, and some part of your credibility is now collateral.

The problem was never that you estimated badly under pressure. You answered a distribution question with a point, and the fix is data you already own and have never looked at.

Why "better estimates" won't fix this

Delivery time is a spread. The same-sized item takes four days or three weeks depending on which queues it hits: review pickup, a blocked dependency, a rework round. Confident dates fail in one direction only - late - because queues add time and never refund it.

The instinct most orgs reach for is velocity: "we do 40 points a sprint, the epic is 200 points, so five sprints." Two problems. Story points are a team-local currency that inflates the moment it's used as evidence, and the SPACE researchers warn flatly against reading productivity off a single metric.

A CEO can't audit a point. A CEO can audit a calendar day, which is exactly why the delivery-performance research runs on real units. DORA's 2024 tiers put elite teams' lead time under a day and low performers at one to six months, and the Accelerate research found high-performing delivery orgs were twice as likely to exceed their profitability, market-share, and productivity goals. Forecasts have to speak that language: real units, from real history.

The cure starts free: forecast from your own history

One afternoon, no new tools, no vendor required.

1. Pull your last 20 shipped items of roughly the kind being asked about. For each, get elapsed time: work started → in production. Timestamps you already have.
2. Sort the durations and read two numbers off the list: the halfway point ("half ship within X days") and the 85th-percentile point ("most ship within Y days"). That pair is your forecast.
3. Answer with the range and the position: "Items like this: half ship inside two weeks, most inside five. This one enters review this week; I'll update you when it clears." You've replaced a guess with your own track record. Nobody can call bullshit on your own shipped history.
4. To tighten the range, shrink the work. Big items have wild distributions; smaller batches ship more predictably, the same reason cycle time benchmarks reward teams that slice work thin. Predictability isn't a personality trait. It's a batch-size setting.

What good looks like: LinearB's benchmarks (8.1M+ PRs) put elite cycle time under 25 hours at p75. Teams in that band can answer the CEO question in days-not-weeks terms, and estimation skill has nothing to do with it. Their history is tight enough to quote.

What to actually say in the meeting

Not "it depends" (true, useless) and not a bare date (crisp, fictional). The shape that works: "Half of our items like this ship within two weeks, most within five. This one just cleared review, so it's on the fast side of that range. The biggest risk to the range is scope we add mid-flight: every addition trades the date." You've given a commitment you can defend, a status you can verify, and you've handed the scope lever to the people who control it. That last part quietly ends the mid-cycle "just one more thing" that was murdering your dates anyway.

Where a tool honestly fits

The manual version decays. Percentiles drift as the team changes, and re-pulling 20 items before every exec meeting won't survive your calendar.

Busfactor keeps the answer live: cycle-time percentiles, throughput, and deploy cadence computed continuously from your actual GitHub history, in real units, every number linked to the PRs behind it. When the range widens, you see which queue stretched it before the roadmap feels it. The same early-warning logic catches a slow quarter before it becomes a slipped year.

Honesty about the limits: no tool forecasts scope you haven't discovered, a pivot, or a dependency's mood. A forecast from history assumes the future resembles the past; when you change the system, the range moves, which is the point. What you get is the honest range and its receipts. What you say in the meeting is still your job.

The door

Before the next exec meeting, spend the afternoon: 20 items, two percentiles, one sentence you can stand behind. Then, if you'd rather the numbers maintain themselves, the delivery view keeps your real ranges current with receipts attached. The next time the room turns to you, you're quoting your org's shipped history instead of the look on your tech lead's face.