Ask a team when a release will land and you usually get a single date. Ask how confident they are and you get a shrug. That gap is the whole problem with forecasting from an average: a velocity-based date carries no information about how wrong it might be, so nobody downstream can price the risk.

Three-point estimation — the technique underneath PERT, the Program Evaluation and Review Technique — fixes exactly that. Instead of one number per item, you capture three: optimistic, most likely, and pessimistic. The arithmetic that follows is trivial. The value is that the spread between the three is a measurement of your own uncertainty, and that spread is the thing a release conversation actually turns on.

The mechanics, briefly

For each item you estimate three values: O (optimistic — everything goes right), M (most likely — the number you would have given anyway), and P (pessimistic — the realistic bad case, not the catastrophe). The PERT expected value weights the middle heavily:

E = (O + 4M + P) / 6

And the standard deviation — the part most teams skip and the part that matters — is:

SD = (P − O) / 6

Across a release you sum the expected values to get a central forecast, and combine the standard deviations in quadrature — the square root of the sum of the squares — to get the uncertainty of the whole. That last step is why three-point estimation is worth the trouble: because independent errors partially cancel, a release of forty uncertain items is proportionally more predictable than any single item in it. A team that only ever quotes worst cases item by item ends up with an indefensibly padded release date.

What it adds that velocity does not

A velocity forecast is backward-looking and aggregate. It answers “at our historical rate, when does this scope finish?” That is a good question and often the right one. But it assumes the coming work resembles the past work, and it flattens every item into the same average.

Three-point estimation is forward-looking and item-specific. It surfaces the two things velocity hides:

• Which items carry the risk. Two stories can share a most-likely estimate of five days while one has a spread of four-to-six and the other three-to-twenty. Only one of those belongs on the critical path of a committed date, and velocity cannot tell them apart.
• Asymmetry. Software estimates are almost never symmetric. The best case is bounded by how fast work can physically be done; the worst case is unbounded. When P sits much further from M than O does, the honest forecast is later than the most likely number — and the PERT formula shows it rather than arguing about it.

Used together they are stronger than either alone. Velocity calibrates the central tendency against what the team has actually delivered; three-point estimation puts a defensible width around it.

Where teams get it wrong

Three failure modes account for most disappointing attempts.

The pessimistic case is not pessimistic. Teams anchor on the most likely number and set P about 20% above it. Real pessimistic cases involve the dependency that arrives late, the test environment that is down for two days, and the reviewer who is on leave. If your P has never once been exceeded, it is not a P.

Estimating everything three ways. This is expensive and unnecessary. Apply three-point estimation to the ten or fifteen items that could plausibly move the release date — the novel work, the integrations, the items with external dependencies — and let the well-understood routine work ride on velocity.

Reporting E and throwing away SD. If you compute the range and then quote a single date anyway, you have done the work and discarded the product. The output of this exercise is a date and a confidence, together, every time.

Keeping the range alive in Jira

A three-point estimate produced once in a planning workshop decays immediately — scope shifts, dependencies resolve or slip, and the spread that was right in week one is wrong by week four. The forecast has to be recalculated as the underlying work changes, or it becomes another spreadsheet nobody trusts.

Advanced Release Planning, Roadmaps & Management for Jira takes the same idea and runs it continuously: it forecasts from your team’s real delivery history and capacity and publishes a date with a confidence band attached, updated as issues move. The discipline three-point estimation teaches — never quote a date without its uncertainty — becomes the default output rather than a quarterly exercise.

The takeaway

Three-point estimation is not a more accurate way to guess. It is a way to make the size of your uncertainty explicit and to stop pretending a forecast is a fact. Apply it to the risky minority of your scope, keep the standard deviation, and report the range. Stakeholders who are given a range and a confidence level make better decisions than stakeholders who are given a date and a shrug.

Part of our guide: this article is a deep dive from the complete guide to release planning for Agile teams in Jira. See also release date forecasting for the throughput-based method, the cone of uncertainty for why ranges narrow only when you make them, and how to read a release date confidence level.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio