Doubling Your Estimates Won't Fix Being Late. This Will.

TL;DR: "It'll take two days" was true - about the work. The two weeks it actually took were the queues: review pickup, blocked handoffs, interrupted focus, rework rounds. Estimates measure touch time; calendars run on elapsed time; and on most teams the gap between them is the whole story. Padding estimates just describes the lateness more accurately. The fix is an afternoon audit (elapsed vs touch time on five recent items), then cutting the waiting instead of re-negotiating the guess.

"How long will this take?" - "Two days." Two weeks later it ships, and everyone quietly absorbs the lesson that engineers can't estimate. Wrong lesson. The engineer was probably right: there were about two days of work in there. What nobody estimated was the twelve days the work spent waiting: for a reviewer, for an answer, for a deploy slot, for the author to reload context after the fourth interruption.

You don't have an estimation problem. You have an elapsed-time problem wearing an estimation problem's clothes. Every hour spent estimating harder is spent on the wrong problem.

The estimate was right about the work and wrong about everything else

An estimate predicts touch time: hands on keyboard, actively building the thing. The calendar runs on elapsed time: first commit to production, queues included. The ratio between the two is flow efficiency, and it's routinely terrible, which is why estimates fail in one direction only. Nobody's estimate is ever too pessimistic. The queues only add.

Where the twelve days actually go, with receipts:

• Waiting for review to start. LinearB's benchmarks (8.1M+ PRs) flag pickup time over 16 hours as "needs focus"; elite teams start in under an hour. For contrast, Google's study of ~9M changes found the entire review process has a median under 4 hours. Days-long pickup is normal on slow teams and it appears in zero estimates.
• Interruptions, billed at resumption rates. Parnin & Rugaber's study of 10,000+ programming sessions found only ~10% of resumed sessions saw an edit within a minute of returning, and ~30% took over half an hour to get back to editing. "It's a quick question" costs the asker a minute and the answerer a context rebuild.
• Looking for answers. In the 2024 Stack Overflow survey, 61% of developers reported spending more than 30 minutes a day just searching for answers or solutions. That's a silent daily tax on every estimate, and it's worse where knowledge is siloed.
• Rework rounds. The feature that "was done" comes back: review findings, churned code, a missed requirement. Rework is real work that was never on the plan, which is also a big reason releases slip.

Doubling the estimate doesn't remove any of these. It just schedules the waiting in advance.

The cure starts free: audit five items, then cut the waiting

One afternoon, tools you already have, useful even if you never buy anything.

1. Take the last five shipped items and reconstruct each one's timeline from timestamps: first commit, PR opened, first review, approval, merge, deploy.
2. Split elapsed time into touch and wait. Be honest - "in review" with no reviewer activity is wait.
3. Compare wait to the original estimate. On most teams the waiting alone exceeds the entire estimate. Seeing that once, with your own tickets, permanently ends the "estimate better" conversation.
4. Then attack elapsed time, in order of leverage: cut work-in-progress so fewer things wait at once (WIP limits are the mechanism), agree a review pickup window (pickup is the cheapest queue to fix), and batch interruptions into windows instead of letting them strafe the day.

What good looks like: elapsed time within shouting distance of touch time. Items that take two days of work take two-to-four days of calendar, not fourteen. Teams in that state discover something pleasant: their estimates were fine all along.

You can't manage the gap you can't see

The trap with the one-off audit: the gap regrows silently. WIP creeps up, a reviewer gets overloaded, and three months later everything is mysteriously late again, and the org reaches for the same wrong lesson about estimation.

This is the honest case for continuous measurement, and it's exactly what Busfactor is built to do: it reads your real GitHub history and shows elapsed time broken into stages - where work waited, for how long, trending which way - every number linked to the actual PRs, plus what the waiting costs in payroll terms, in your currency.

What it can't do, stated plainly: it can't measure thinking time, can't see the hallway interruption, and it will never tell you what a task should have taken. It measures the waiting, and the waiting is where your calendar went.

The door

Run the five-item audit this week. When the wait time dwarfs the estimate - it will - stop the estimation retro you had planned and cut WIP instead. And if you want the gap watched permanently rather than audited once: the flow view keeps the touch-vs-wait picture live, so "everything takes longer than estimated" turns from your team's weather into a queue with a name, a trend, and a fix.