Skip to main content

Estimation

An estimate is a forecast made under uncertainty, not a promise. Its job is to inform a decision and surface risk, not to be proven right. The moment an estimate is treated as a commitment, people stop estimating honestly and start negotiating, and the number loses all of its value.

Why this matters​

The playbook already assumes you can estimate. The "definition of ready" in Communication & Collaboration requires every ticket to be estimated before it enters a sprint, and the career ladder in Learning & Growth expects a mid-level engineer to "estimate work accurately." Until now we never said how. This section closes that gap.

Estimation is where Integrity and Care meet delivery. Clients plan budgets, launches, and their own commitments around the numbers we give them, so an optimistic guess dressed up as a date is not harmless, it is a small breach of trust that compounds. A team that estimates honestly (with ranges, stated assumptions, and the discipline to re-estimate when scope moves) keeps the predictability that client relationships are built on. A team that quotes single dates to look confident spends the rest of the project explaining why it slipped.

The standard​

What an estimate is, and what it is not​

Three words get used interchangeably and should not be:

TermWho owns itWhat it means
EstimateThe people doing the workAn honest forecast of effort, with uncertainty attached. "Most likely 3 days, could be 5."
TargetThe business or clientA desired outcome. "We want this for the trade show on the 20th."
CommitmentThe team, deliberatelyA date the team agrees to hit, derived from the estimate plus a chosen confidence buffer.

The failure mode is collapsing all three into one number. A target is not an estimate (wanting it sooner does not make it shorter). An estimate is not a commitment (a forecast becomes a promise only when the team consciously adds buffer and agrees to it). Keep them separate in your own head and in conversations with clients, and most estimation conflict disappears.

The other rule: estimates are owned by the people who will do the work. An estimate handed down by a manager or a salesperson is a target wearing an estimate's clothes. If the engineer who picks up the ticket did not shape the number, it is not their estimate and they will not stand behind it.

Three-point estimation (PERT)​

Single-number estimates hide the one thing that matters most: how uncertain you are. "5 days" tells the reader nothing about whether you mean "5 days, easy" or "5 days if nothing goes wrong, and plenty could." Three-point estimation makes that uncertainty explicit.

For each task, capture three numbers:

  • Optimistic (O): everything goes right. The realistic best case, not a fantasy.
  • Most likely (M): your honest single-point guess if you had to give one.
  • Pessimistic (P): the realistic worst case. Not the apocalypse, but "the integration fights back, the requirement was fuzzier than it looked, a dependency is late."

PERT combines them into a weighted expected value and a measure of spread:

Expected effort   E     = (O + 4M + P) / 6
Standard deviation sigma = (P - O) / 6
Variance               = sigma^2

The weighting (4 parts most-likely to 1 part each of the extremes) reflects that the middle is where reality usually lands, while still letting a long worst-case tail pull the expected value upward. That upward pull is the point: it is the math quietly correcting for the optimism every engineer carries.

Worked example: a CSV export endpoint.

  • O = 1 day (the data model is clean, a library does most of it)
  • M = 2 days (the realistic case)
  • P = 5 days (pagination, large-file streaming, and edge-case formatting turn out to be real work)
E     = (1 + 4*2 + 5) / 6 = 14 / 6 = 2.33 days
sigma = (5 - 1) / 6       = 4 / 6  = 0.67 days

So the honest answer is "about 2.3 days, plus or minus 0.7," not "2 days." Notice the expected value (2.33) sits above the most-likely guess (2): the wide pessimistic case has correctly nudged it.

Rolling estimates up with the S&P template​

Per-task numbers are only useful once they roll up into a forecast for the whole feature or project. The S&P PERT estimation template does this for you: enter O, M, and P per task and it computes E, sigma, and the totals.

The roll-up math is not "add up the expected values and add up the standard deviations." Expected values add, but variances add, standard deviations do not:

Project expected effort = sum of each task's E
Project variance        = sum of each task's variance (sigma^2)
Project sigma           = sqrt(project variance)
TaskOMPEsigmavariance
CSV export endpoint1252.330.670.44
Auth on the new route2373.500.830.69
Frontend download button + states0.5131.250.420.17
Project7.081.141.30

Project sigma is sqrt(1.30) = 1.14 days, not the 1.92 you would get by adding the three standard deviations. This is the most useful property of the method: because risks partly cancel out, a project is proportionally more predictable than its riskiest single task. Use the sigma to express confidence, assuming a roughly normal spread:

  • E (about 7.1 days): roughly 50/50. Half your projects quoted this way finish late.
  • E + 1 sigma (about 8.2 days): about 84% likely to be enough.
  • E + 2 sigma (about 9.4 days): about 98% likely to be enough.

That is how you turn a spreadsheet into a sentence for a client: "Most likely around 7 days; we would commit to 9 to be safe." You are no longer guessing at a buffer, you are choosing a confidence level.

Two honest caveats the template does not enforce, so you must:

  • The math assumes the tasks are independent. In reality, if one task runs long because the requirement was vague, related tasks often slip for the same reason. Correlated risk makes the real spread wider than the formula suggests. Treat the computed sigma as a floor on your uncertainty, not a ceiling.
  • Classic PERT sums along the critical path (the longest chain of dependent tasks in a network), not every task in the backlog. For most S&P feature work, sum the tasks on the longest dependency chain. If work is genuinely parallel across people, estimate each person's chain separately rather than summing everything into one inflated number.

Choosing the right tool: PERT, story points, or t-shirt sizing​

PERT is precise but it costs time. Do not apply it to everything.

MethodBest forWhy
Three-point / PERTFeature and project forecasts, anything a client commitment hangs onProduces a defensible range and a confidence level. Worth the effort when the cost of being wrong is real.
Relative sizing / story pointsThe sprint backlog, sprint-over-sprint planningFast, and velocity turns points into a forecast over time without per-task time guessing.
T-shirt sizing (S/M/L/XL)Early roadmap and triage, before requirements are firmHonest about coarse uncertainty. Stops you from inventing false precision on work you barely understand.

The anti-pattern is precision theatre: running a full three-point estimate on a one-line bug fix, or quoting "0.8 story points." Match the effort of estimating to the cost of being wrong. A one-line fix is "small, do it today." A three-month client commitment earns the spreadsheet.

From estimate to commitment​

An effort estimate is not a delivery date. Turning one into the other means accounting for everything that is not heads-down coding:

  • Non-coding time is most of the slip. Code review turnaround, QA and bug-fix cycles, the deploy itself, standups and meetings, context-switching between tickets. If your estimates only cover writing code, they are systematically and predictably short.
  • Respect the definition of ready. Per Communication & Collaboration, a ticket that lacks clear acceptance criteria cannot be estimated honestly. If you cannot give a sane pessimistic number, the task is not ready, it is research. Estimate the research as its own task (a spike) and re-estimate the work once you know more.
  • Estimates feed planning, they do not replace it. Project-level forecasts inform the release cadence and stakeholder alignment (S&P ships at the end of each sprint, so estimates frame which sprint a feature realistically lands in), and per-ticket estimates feed sprint planning. The estimate is an input, the plan is the decision.

When you commit to a client, commit to a confidence level, not the bare expected value. Quoting E means roughly half your features ship late. Quoting E + 1 or 2 sigma is the difference between "usually on time" and "the client stopped trusting our dates."

Tracking actuals and improving​

Estimation is a skill, and skills only improve with feedback. The loop is cheap and most teams skip it:

  • Record what actually happened. Capture actual effort against the estimate. Jira hygiene already asks you to comment when a ticket runs long ("if a ticket takes twice as long as estimated, a brief comment explaining why helps future estimation"), this is what that note is for.
  • Look for the pattern, not the miss. One task running over is noise. The same person or team consistently underestimating a category of work (anything involving third-party integrations, say) is a signal you can correct for next time.
  • Bring it to the retro. Estimation accuracy is a legitimate, low-drama retrospective topic. The goal is calibration, not blame. A team that knows it underestimates integrations by 50% and adjusts is estimating well, even when the first guess was off.

Critical thinking​

  • Estimates are not commitments, and padding in secret destroys the difference. The honest way to be cautious is a wider pessimistic number and an explicit confidence level the client can see. Quietly inflating a single number to protect yourself trains everyone to distrust every number you give, including the ones you did not pad.
  • The planning fallacy is not a personal failing, it is a species-wide bias. People underestimate their own tasks even when they have watched identical tasks run long before. PERT only helps if the pessimistic point is genuinely pessimistic. If your P is just M plus a little, you have not escaped the bias, you have decorated it.
  • #NoEstimates has a real point. For well-understood work sliced into small, similar pieces, counting throughput (how many tickets the team actually closes per sprint) forecasts more accurately than estimating each item, because it measures reality instead of predicting it. Reach for per-task estimation when the work is novel or a commitment depends on it, not by reflex.
  • Garbage in, garbage out. The formula cannot rescue a vague requirement. A confident-looking E computed from three numbers you pulled out of the air is more dangerous than an honest "we do not know enough to estimate this yet," because it launders a guess into something that looks like analysis.
  • Three points from one person is one person's blind spots. For anything that matters, estimate together. The value of planning poker or a quick group three-point pass is not the average, it is the conversation when two people give wildly different P values: that gap is a hidden assumption or an unspoken risk, surfaced before it bites.

Checklist​

For every task you estimate​

  • Optimistic, most-likely, and pessimistic values are all captured, not just a single number
  • The pessimistic value reflects a realistic bad case, not the most-likely value with a token margin
  • Non-coding time (review, QA, deploy, meetings) is included or accounted for elsewhere
  • Dependencies and assumptions are written down next to the estimate
  • The task meets the definition of ready; if not, it is estimated as a spike instead

For every project or feature forecast​

  • Task estimates are rolled up through the S&P template (variances summed, not standard deviations)
  • A range and a confidence level are communicated, never a single bare date
  • The chosen commitment date sits at a deliberate confidence level (E + 1 or 2 sigma), not at E
  • Assumptions and excluded scope ("we are not doing X") are stated explicitly to the client

Ongoing​

  • Actual effort is recorded against the estimate
  • Estimates are revised when scope changes, rather than left stale
  • Estimation accuracy is reviewed periodically in retrospectives, for calibration not blame

AI tips​

  • Decompose a feature into estimable tasks. Paste the requirement or ticket and ask AI to break it into a task list, then sanity-check the breakdown. AI is good at remembering the steps you forget (migrations, error states, the deploy), which are exactly the tasks that get left out and cause slips.
  • Generate starting points for O, M, and P, then correct the P. AI can propose three-point values from a task description, but it skews optimistic and its pessimistic case is usually too tame. Treat its O and M as a reasonable first draft and widen the P yourself based on what you know about this codebase and client.
  • Have AI hunt for risks that should widen the pessimistic estimate. Ask "what could make this take much longer than expected?" It surfaces integration edge cases, auth and permission complexity, and data-migration gotchas that justify a larger P. This is more valuable than asking it for the estimate itself.
  • Draft the client-facing summary from the spreadsheet. Give AI the rolled-up E and sigma and ask it to write the range in plain, non-technical language ("most likely around X, we would commit to Y"). It is good at translating the math into a sentence a non-engineer can act on, the same skill described in Communication & Collaboration.
  • Do not let AI invent confidence. AI has no memory of your team's velocity or this client's history, so any number it gives is a generic prior, not a calibrated estimate. Use it to structure and pressure-test your thinking, never as the source of the final commitment.

Resources​

S&P internal:

Playbook cross-references:

External references: