Guide

A single number implies false precision. Ranges force you to name what drives the upper bound.

Prefer:

  • "3–5 eng-days for the API, 70% confidence; the webhook edge cases are the wild card."
  • "Calendar: end of next week if the payments team reviews within two days; add a week if not."

Concept

You already have a raw breakdown. This page is how you turn that sum into something a stakeholder can trade against.

Walking through the padding factor

When the work is unfamiliar, apply a padding factor consciously rather than secretly padding every line.

FamiliarityMultiply raw task sum by
Done this exact pattern last quarter1.2–1.3 (review + glue)
Known domain, new subsystem1.5–2
New domain or new dependency2–3, plus a spike first

Say the factor out loud: "My raw sum is 8 days; I have never touched FraudSvc, so I am quoting 16–20 with a two-day spike up front." Stakeholders can argue with the factor; they cannot argue with a hidden one.

Example

Raw breakdown for "add export CSV for admin reports": schema 0.5d, query 1d, streaming upload 1d, permissions 0.5d, tests 1d, review/QA 1d → 5 days raw. You have not used the company's object-storage helper before → ×1.6 → 8 days, quote 1.5–2 weeks calendar with one other project in flight.

Fold that into the folders example. Raw sum 10 eng-days. Personal factor 1.4 on the unfamiliar ACL line (2 × 1.4 = 2.8), others × 1.3 → calibrated ≈ 13 eng-days. With meetings and a design-review dependency, calendar for one full-time engineer is roughly 3 weeks.

Calendar is not eight focus hours

A realistic planning model many ICs use:

Focus hours per day ≈ 4–5 (rest is meetings, review, Slack)
Focus days per week ≈ 4 (one day lost to ritual + interrupts)
Effective eng-week ≈ 16–20 focus hours ≈ 2–2.5 "ideal" eng-days of estimate

So a "5 eng-day" task is often two calendar weeks if you are also on-call, reviewing, and in discovery meetings. When you quote calendar dates, bake this in or you will look unreliable while working hard.

On-call week: cut planned project load by ~50% unless the rotation is historically silent. Say so in the plan.

Common mistakes

  • Padding secretly instead of stating uncertainty.
  • Estimating only coding time.
  • Planning as if you have eight focus hours a day every day.
  • Estimating in story points that never convert to calendar time anyone believes.

Check yourself

Raw sum is 8 days. You have never touched FraudSvc. What do you quote?

Something like 16–20 days plus a two-day spike, with the factor said out loud.

A "5 eng-day" task sits next to on-call and a pile of reviews. How many calendar weeks?

Often about two. Focus time is 4–5 hours a day, not eight.

Key takeaways

  • Quote ranges and confidence. Name what drives the upper bound.
  • Multiply consciously for unfamiliarity. Say the factor out loud.
  • Calendar dates must include meetings, review, and on-call — not just coding.
  • Hidden padding destroys trust; visible padding starts a negotiation.

Further learning

Next, spend the calendar on the right work first: de-risking and milestones.