Engineering estimates are wrong by a factor of 2-3 by default. The planning fallacy is universal — you imagine the happy path, forget the integration work, ignore the things you don't know yet. The fix isn't 'estimate better'; it's 'estimate differently'.
Decompose to <2 day tasks
If a task is 'build the feature' (1 month), the estimate is fiction. Break to '<2 days each'. The tasks you can't estimate at this level are the ones hiding unknowns — that's where the real work is.
Estimate by reference, not by feel
'How long did the last similar feature take?' beats 'I think this is 3 days'. Build a reference list. New estimate: similar reference × adjustment factor for known differences. Calibrated; quickly improves.
Track three numbers
Optimistic (everything goes right). Realistic (typical). Pessimistic (something hidden bites). Most estimators give the optimistic. Communicate the realistic; track the pessimistic.
Budget for integration and review
Coding the feature is half the work. Review cycles, integration with adjacent systems, bug fixes from QA, documentation. Add 50-100% to coding time. Skip this and you're chronically late.
Re-estimate, don't fix the schedule
Two weeks in, the estimate is wrong. Update it. Don't just push harder to hit the original. Re-estimating publicly trains the org to take new estimates seriously and to plan around realistic dates.