OneMorePoint

Sign in

Three-Point (PERT) Estimation

Agile Estimation

Three-Point (PERT) Estimation

Three-point estimation asks for three numbers instead of one - optimistic, most likely, and pessimistic - and combines them into a weighted expected value with a built-in confidence range. It's the outlier in the agile estimation technique family: every other technique in the complete guide is relative (comparing work to other work); three-point is absolute (predicting actual duration or effort). This page covers how it works, when it's the right tool, and when it isn't.

The formula

Each estimator provides:

  • Optimistic (O) - best case, everything goes right
  • Most likely (M) - what you'd honestly expect
  • Pessimistic (P) - worst case, real problems show up

Expected value = (O + 4M + P) / 6

The most-likely case counts four times as much as either extreme, which is why the result leans toward what you'd normally expect rather than splitting the difference between best and worst case. The spread between optimistic and pessimistic also produces a standard deviation - (P − O) / 6 - giving the estimate an explicit confidence range instead of one number presented as certain. Run your own numbers: PERT / three-point calculator.

Where this technique came from

Three-point estimation is PERT (Program Evaluation and Review Technique) analysis, developed for the U.S. Navy's Polaris missile program in the late 1950s to estimate project schedules under genuine uncertainty. It predates agile software estimation by decades and remains standard in traditional project management, which is why it shows up in agile contexts mainly at the boundary where software estimation has to talk to a schedule.

When three-point estimation is the right tool

A stakeholder needs a schedule with a confidence range, not a story-level plan. "This epic will likely take 6 weeks, with a realistic range of 4 to 9" is a genuinely useful sentence for a roadmap conversation - it commits to less false precision than a single point estimate while still being usable for planning.

Estimating large pieces of work - epics, features, quarters - rather than sprint-ready stories. Three-point estimation is slower per item than Scrum Poker, so it doesn't scale to sprint-level story-by-story sizing. It fits the handful of large, high-stakes estimates a quarter actually needs, not the dozens of small ones a sprint does.

The audience is used to schedules, not story points. A number expressed in weeks or days, with a stated confidence range, communicates to a non-technical stakeholder in a way "34 story points" simply doesn't.

When it isn't

Sprint-level story sizing. Running three-point estimation on every backlog item defeats its own purpose - it's slower than Scrum Poker per item and produces a mathematically averaged output rather than a team consensus, which is the exact thing group estimation through discussion is trying to capture. Full comparison: three-point estimation vs. planning poker.

When the team needs a velocity number. Three-point outputs feed schedule math, not points-per-sprint. If the goal is tracking a team's delivery rate over time, story points and velocity are the right unit, not a PERT expected value.

When "most likely" is really just a guess. The formula only produces something meaningful if the three inputs reflect real judgment about the work. Three confident-sounding numbers for work nobody understands yet just produces false precision with extra math - a spike to reduce the actual uncertainty is the better move first.

A worked example

A team needs to estimate "migrate the reporting service to the new data warehouse" for a stakeholder who wants a schedule commitment, not a sprint-level plan.

  • Optimistic: 3 weeks - if the schema mapping turns out to be mostly mechanical.
  • Most likely: 5 weeks - based on how similar migrations have gone before.
  • Pessimistic: 10 weeks - if the warehouse's rate limits force a slower, batched migration approach.

Expected value = (3 + 4×5 + 10) / 6 = 33 / 6 ≈ 5.5 weeks

Standard deviation = (10 − 3) / 6 ≈ 1.2 weeks

The team communicates this as "about 5.5 weeks, with a realistic range of roughly 4.3 to 6.7 weeks" - a number that's honest about the uncertainty instead of committing to a single date the pessimistic case could blow past.

Three-point estimation and the cone of uncertainty

This technique makes the most sense used at the point in the cone of uncertainty where a piece of work is understood well enough to bound optimistic and pessimistic cases meaningfully, but not so well understood that it's already broken into sprint-ready stories. Too early, and all three inputs are guesses; too late, and the work should already be in Scrum Poker rounds at the story level.

Calculate your own estimate

Skip the manual math: the PERT / three-point calculator takes your three inputs and returns the expected value and confidence range instantly.

Frequently asked questions

Expected value = (optimistic + 4 × most likely + pessimistic) / 6. The most-likely case counts four times as much as either extreme, so the result leans toward what you'd normally expect.
Agile Estimation Techniques: A Complete GuideA full comparison of agile estimation techniques - Scrum Poker, t-shirt sizing, affinity estimation, the bucket system, dot voting, Wideband Delphi, and three-point estimation - with guidance on which fits your team and when.Agile Estimation Techniques: Comparison MatrixA printable one-page matrix comparing every major agile estimation technique - what it optimizes for, team size, whether it feeds velocity, and when to use it - condensed from the full agile estimation guide.T-Shirt Sizing for Agile EstimationHow t-shirt sizing (XS-XXL) trades precision for speed, when it beats Scrum Poker, and the real limitation - t-shirt sizes don't sum into a velocity number without a mapping.Relative Estimation: The Idea Behind Every Agile TechniqueWhy comparing work to other work beats predicting absolute duration - the human-limitation research behind it, and a worked door/house example that needs no software background.Affinity Estimation: Sizing a Large Backlog FastHow silently sorting backlog items along a size spectrum sizes dozens of items in minutes - the mechanism, a worked 80-item example, and what the speed costs you.The Bucket System: Estimating Very Large BacklogsA more structured, more parallelizable version of affinity estimation for portfolios with hundreds of items - how it works, a worked 300-item example, and when the extra structure earns its keep.Wideband Delphi: The Root of Scrum PokerHow the Delphi forecasting method (RAND Corporation, 1950s) became Barry Boehm's software cost-estimation technique, and why its independent-judgment-then-discussion structure is the direct ancestor of Scrum Poker.Dot Voting: Prioritization, Not EstimationWhy dot voting answers "what matters most," not "how big is this" - how the technique works, where it genuinely fits, and the common mistake of using it as an estimation shortcut.

Put it into practice

Create a free Scrum Poker room and estimate with your team - no sign-up needed.