Evidence-based scheduling

Joel Spolsky's Evidence-Based Scheduling (EBS) idea: track estimate vs actual per person over many small tasks, then simulate ship dates with that historical error distribution (Monte Carlo) instead of summing best-case guesses. Even without FogBugz, you can steal the spirit.

You will still be wrong sometimes. You will be wrong less often, and your manager will trust your ranges because they are grounded in your history.

Walking through a personal factor

1. Break work into small tasks.
2. Record your estimate and your actual elapsed time (including debugging).
3. After a few months, know your personal factor (for example you run ~1.4× on backend tasks, ~1.8× on unfamiliar infra).
4. Apply that factor before you quote a date.

Last 20 tasks: actual / estimate median = 1.45
New project raw estimate = 10 eng-days
Calibrated = 10 × 1.45 ≈ 14.5 eng-days
With meetings (~20% calendar drag): ~18 calendar days for one person

That is the same honesty as the padding table, except the multiplier comes from your last twenty tasks, not a guess about FraudSvc.

Re-estimate when:

• A spike changes the design.
• A dependency date moves.
• You burn 50% of the buffer with 30% of the work done.
• Scope grows by more than a small task.

Do not wait for the original end date to "see what happens." Mid-flight re-estimates should be boring: update the milestone table, send a short yellow status, propose the scope/date trade. Teams that treat re-estimation as failure learn to hide; teams that treat it as hygiene ship more honestly.

Common mistakes

• Summing best-case guesses and calling it a plan.
• Tracking estimates but ignoring debugging and review in the actuals.
• Treating a re-estimate as a confession instead of hygiene.

Check yourself

Your last 20 tasks ran at 1.45×. Raw estimate is 10 days. What do you quote before calendar drag?

About 14.5 eng-days. Then add meetings.

You have used 50% of the buffer and finished 30% of the work. What now?

Re-estimate this week. Do not wait for the original end date.

Key takeaways

• Your history is a better multiplier than optimism.
• Record estimate and actual, including debugging, on small tasks.
• Apply the factor before you quote. Re-estimate when the plan and reality diverge.
• Re-estimation is hygiene, not failure.

Further learning

Next, say the new number out loud: communicating slips.

Evidence Based Scheduling (Joel Spolsky)Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce t…Joel on Software