Three Point Estimating

Schedule technique · See it on the map

Runnable here

Combining an optimistic, a pessimistic, and a most-likely estimate into one figure.

When to use it

Use it whenever a task has real uncertainty and you have someone (or several people) who can credibly bound it with a best case, worst case and most likely case — new or unfamiliar work, work with dependencies outside your control, anything where a single-point guess would be overconfident.

When to avoid it

Don't use it for well-understood, repetitive work where the range would just collapse to the most-likely point anyway — that's overhead without benefit. And don't use it if the three points are all supplied by one person guessing under time pressure; the technique's value comes from someone actually reasoning about best/worst case, not from three numbers filled into a template.

Steps

1. For the task, gather three estimates: optimistic (O, everything goes right), pessimistic (P, everything that plausibly goes wrong does), and most likely (M, the realistic case).
2. Combine them with either the triangular formula, E = (O + M + P) / 3, which weights all three points equally, or the beta/PERT formula, E = (O + 4M + P) / 6, which weights the most-likely estimate four times as heavily as either extreme and is the more common default.
3. Optionally compute a standard deviation, SD = (P - O) / 6, to express the estimate's spread rather than just its center — useful when several such estimates need to be combined into a project-level confidence range.
4. Record all three original inputs alongside the combined estimate, not just the final number — the range itself is information a single point throws away.

What it produces

• A combined single-point estimate (E) suitable for building the schedule, plus the three original inputs and, optionally, a standard deviation expressing confidence — noting that Driftless today stores only the final E, so the O/M/P spread has to live in the worked notes rather than the product's task record.

Common pitfalls

• The pessimistic estimate gets softened because naming a truly bad outcome feels uncomfortable, which quietly turns three-point estimating back into a single-point guess with extra steps.
• The optimistic case is treated as achievable rather than as the best case, and the final estimate drifts toward it under schedule pressure.
• The triangular and beta/PERT formulas get mixed up mid-project, so estimates from different tasks aren't actually comparable even though they look like the same kind of number.

Worked example

A task to integrate a third-party payment gateway gets estimates of O = 3 days (the documented happy path holds), M = 6 days (typical integration work with one or two surprises), P = 14 days (the gateway's sandbox environment turns out unreliable, as it has on a past project). Beta/PERT gives E = (3 + 4*6 + 14) / 6 = 6.83 days, versus a plain average of (3 + 6 + 14) / 3 = 7.67 days — the beta/PERT figure sits closer to the most-likely case because it weights M four times as heavily as either tail.

Source

• PMBOK-6 §6.4.2.4

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.