Estimation & Planning

Estimates are not promises. They are informed guesses that help the team plan, and they should be honest by design. The goal is not to be exactly right (you cannot be). It is to communicate uncertainty clearly, break work into understandable pieces, and raise risk early. An estimate given to please someone, then quietly missed, helps no one.

Software estimation is genuinely hard, and that is normal. The work is new, dependencies surprise you, and the unknowns only appear as you go. What makes an estimate useful is not false precision. It is honesty about how confident you are, breaking work into small pieces you can reason about, and updating the picture as you learn. This ties directly to the honesty standard (see Professional Ethics) and to how we communicate.

This matters most for junior engineers. It is normal to be uncertain, and normal to be wrong. It is far better to say "I am not sure; here is my range and what could make it much bigger" than to give a confident number you cannot hit.

Estimate honestly

• DoBreak work into small, understandable pieces. Small things are far easier to estimate and to deliver (see Trunk-Based Development).
• DoCommunicate uncertainty. Give ranges or confidence levels, and name the assumptions and unknowns the estimate depends on.
• DoUpdate estimates as you learn. An estimate is a living guess, and re-forecasting early helps the team rather than failing it.
• AlwaysGive honest estimates, not ones meant to please. Raise delays as soon as you see them, not at the deadline (see Professional Ethics, Communication).
• ConsiderIncluding time for testing, review, edge cases, and the unexpected — the parts juniors most often forget — not just the code that handles the normal case.

Plan realistically

• DoFlag risks and dependencies early so plans can account for them, instead of discovering them at the end.
• DoPrefer delivering in small, working increments over one big delivery, so value arrives early and plans can adapt (see Backward Compatibility, Feature Flags).
• AvoidPadding estimates secretly or adding hidden buffer. Be open about uncertainty instead, so trust stays intact.
• AvoidCommitting to a date by quietly cutting testing, security, or quality to hit it. Raise the trade-off openly instead (see Technical Debt).

Self-review checklist

• AskIs this work broken down small enough that I can actually reason about it?
• AskHave I communicated my uncertainty and the assumptions behind the number?
• AskDid I include testing, review, and the unexpected, or just the coding?
• AskIf I am falling behind, am I raising it now rather than hoping to catch up?