Estimation Language

Estimation vocabulary: story points (relative effort units), t-shirt sizing (S/M/L/XL estimates), ballpark estimate (rough approximation), rough order of magnitude (ROM) (estimate within 50-100% accuracy), spike (research task to reduce uncertainty), velocity (team's historical delivery rate), buffer (contingency time added to estimates), scope creep (unplanned additions that expand the estimate). Each appears in planning meetings and project discussions.

Communicating uncertainty: "My rough estimate is 3-5 days — but I'd want to spike on the authentication flow first to confirm", "This is a ballpark figure; the actual effort depends on [X]", "Based on similar work, I'd estimate 2 weeks, plus or minus 20%", "I can give you a more accurate estimate after we've completed the design phase", "This is a ROM estimate — it could be anywhere from 1 to 4 weeks until we understand the requirements better."

Critical distinction: Estimate — a data-based approximation with acknowledged uncertainty ("probably 2 weeks"). Forecast — a prediction based on current velocity and backlog ("at current pace, we'll finish in Sprint 12"). Commitment — a promise to deliver by a specific date, implying shared accountability. Developers should be able to distinguish these: giving an estimate but having it treated as a commitment is a common source of frustration.

Professional deadline pushback: "Based on our current velocity and the scope, 2 weeks isn't realistic — I'd estimate 4 weeks minimum", "To hit that date, we'd need to cut [X feature] or add another engineer", "What would we need to descope to meet that deadline?", "I can commit to [smaller scope] by [date] — the full scope needs more time", "Can we validate the requirement before we commit to a date? We might find a faster path." Frame it as problem-solving, not refusal.

A spike is a time-boxed research task to reduce uncertainty before estimating — "Let's do a 2-day spike to explore the payment API before we estimate the full integration." Types: technical spike (explore technology), functional spike (clarify requirements). A spike has a fixed timebox and a defined output (a recommendation or prototype). Used when a story is unestimable due to unknown technical complexity.

T-shirt sizing uses S/M/L/XL (sometimes XS and XXL) instead of numeric story points. Used for: high-level estimation early in a project, comparing epics and initiatives, portfolio planning when precise estimates aren't possible. In conversation: "Let's t-shirt size these epics for the roadmap — I'd call the payment integration an L, the reporting module an XL." T-shirt sizing is relative, not absolute — what's L for your team may be M for another.

Explaining variance: "Software estimates are inherently uncertain because we're building something new — unlike manufacturing, we can't predict exact duration for creative problem-solving", "Think of it like asking how long a research paper will take — it depends on what you find", "Our estimates get more accurate as we learn more — the first estimate has 50% variance, but after the design phase it narrows to 20%". Use analogies; avoid defensive language.

Planning poker is a consensus-based estimation technique: each team member independently selects a card (Fibonacci: 1, 2, 3, 5, 8, 13) representing their story point estimate, then all reveal simultaneously. If estimates diverge (e.g., some say 3, others say 13), discuss the differences — they reveal different assumptions. The discussion is more valuable than the final number. Run it with: "Everyone, please pick your estimate and we'll reveal on three."

Hofstadter's Law states: "It always takes longer than you expect, even when you take into account Hofstadter's Law." It's a humorous but accurate observation about software projects. In practice, use a 1.5–2× multiplier on your first estimate to account for hidden complexity, interruptions, and scope changes. When someone asks "how long?", experienced engineers say "twice as long as I think" as a rule of thumb — and they're usually right.

The cone of uncertainty describes how estimate accuracy improves as a project progresses. At project initiation, estimates can be off by 4× (25% to 400% of actual). After requirements are set, accuracy improves to 1.5-2×. After detailed design, to 1.1-1.25×. This is why: initial estimates should be presented as ranges, not single numbers; estimation gets more accurate with more information; committing to exact delivery dates at the start of a project is unreliable.