If you’ve ever planned a software project, you’ve probably used three-point estimation, optimistic, most likely, pessimistic. PERT-style scheduling has run on those three numbers for sixty years. The math behind it is fine. The numbers people give you are, for the question they’re answering, roughly honest.
The problem is the question.
“How long does this task take?” assumes the person doing it exists in a vacuum, fully available, fully focused, working on nothing else, executing a plan that doesn’t change. That isn’t the delivery question. The delivery question is “when does this ship?”, and that depends on the entire system around the task, not the task itself.
The Hidden Assumption
Three-point estimation, as it’s commonly used, assumes infinite availability, an isolated project, and predictable resource consumption. You estimate how long the task takes, as if the person doing it has nothing else going on.
The reality? People get sick. They take vacations. They work across timezones. They juggle multiple projects. They aren’t available on the dot. Estimators carry biases they aren’t even aware of. And plans change, rapidly, because you learn the most the moment you start building.
Try it: Three-Point Estimate
Drag the sliders to set your optimistic, most likely, and pessimistic estimates.
The Construction Fallacy
This estimation style was borrowed from the construction industry, where it makes more sense. Construction is repetitive, you’ve poured a thousand foundations, you know how long the next one takes. The unknowns are fewer, and extensive surveys are done upfront to eliminate them.
And yet, even construction fails to predict properly. Projects overrun. Budgets blow up. Despite having far fewer unknowns and far more historical data than we do.
Now imagine what that means for software engineering, where most of what you do is discovery. You’re working on the edge, building something that hasn’t been built before, solving problems you haven’t fully understood yet. You can uncover a lot of unknowns upfront, but you can’t uncover all of them. Ever.
The Task Isn’t the System
The three-point estimate captures the task. It misses everything around it.
- Availability, is the person actually free to work on this, or are they split across three projects?
- Estimator bias, some people consistently underestimate, others overestimate. Without calibration, your inputs are skewed before you even start.
- Plan volatility, the plan you estimated against won’t be the plan you execute. Priorities shift, scope changes, blockers appear.
- Context switching, a 4-hour task doesn’t take 4 hours when it’s spread across three days between meetings and other tickets.
- Discovery, you will find things you didn’t expect. The question is how much, not whether.
Three-point estimation captures none of this. It gives you a range for the task, not for the delivery.
Now add reality
Toggle real-world factors and watch the estimate shift. The original triangle stays as a ghost.
Why Reality Skews Right
Notice something about that list: every factor on it only ever makes things later. Context switching doesn’t accidentally speed work up. Discovery doesn’t shorten the plan. Blockers don’t unblock themselves early. Availability surprises trim your runway, they don’t extend it.
System-level factors are one-directional. That asymmetry is exactly what produces the long right tail you see in real delivery data. It isn’t a quirk of the math, it’s a property of the world. A task-in-a-vacuum estimate is roughly symmetric because tasks-in-a-vacuum are roughly symmetric. Delivery is skewed because reality only pushes one way.
This is what an honest distribution has to capture.
Three-Point Estimation Already Produces a Beta
Here’s the part that’s often missed: PERT’s three points are the standard way to parameterize a beta distribution. The familiar (O + 4M + P) / 6 mean comes from a beta whose shape parameters are derived from your three inputs. This isn’t “use a beta instead of three-point estimation”, three-point estimation has been a beta the whole time.
Your three points already are a beta
Drag the sliders. PERT is doing this math whether you draw the curve or not. Notice how unlikely your "most likely" actually is.
And beta is a reasonable shape for delivery, but the reason isn’t just that it can skew. It’s that it’s bounded. The obvious alternative for right-skewed durations is lognormal, with its unbounded tail. But delivery isn’t unbounded: a task won’t take infinite time, because at some point the project gets cancelled, scope gets cut, or someone else takes it. An unbounded tail keeps assigning probability to outcomes that can’t happen, and downstream, when you simulate against it, that phantom mass pushes your confidence dates into fiction. Bounded support isn’t a limitation here. It’s the point.
What’s wrong is what we feed it. Plug in task-in-a-vacuum numbers and you get the distribution of how long the task takes in a vacuum, a precise answer to a question nobody should be asking. Plug in system-aware numbers, accounting for availability, calibrated bias, expected discovery, plan volatility, and the same machinery answers a different question: “what’s the probability this ships by this date?”
Same distribution. Different inputs. Different question. Right one.
Rethinking the Question
Stop asking “how long will this task take in ideal conditions?” Start asking “given everything we know about how work actually flows through this team, what does the distribution of possible delivery dates look like?”
That’s harder to answer. It requires calibrating your estimators, modeling availability and concurrency, owning that the plan will shift, and treating discovery as a parameter rather than a surprise. But it’s the question that actually predicts delivery, and once you’re asking the right question, the math you already had does the rest.
In a future post, we’ll take these distributions and feed them into something far more interesting.