What the Task Time Estimator does
This estimator answers one question: given what similar tasks actually took, how long will this one take, and how wrong could that be? It works from a list of your own historical durations - not from a dependency graph - and it answers with a band rather than a single number that will be wrong.
It reports the mean, the median and the spread, a prediction interval for the next single task, a confidence interval for the long-run average, a log-normal fit for the right-skewed shape most durations actually have, and a commitment figure taken straight from your data: the duration that 80% of your past tasks came in under. That last one is a real observation, which makes it much harder to argue away than a calculated average.
How to use it
- Paste the durations of comparable past tasks, separated by spaces, commas or new lines. They must genuinely be the same kind of work - mixing two kinds of task produces a spread that describes neither.
- Pick the unit, the confidence level and the confidence at which you want to commit.
- Optionally add a three-point estimate. Entering both is the most useful thing on the page, because it checks your judgement against your own record.
- Read the headline commitment figure, then the bands table - the prediction interval is the one that describes this task.
- Add contingency if your organisation requires it, and copy the estimate with its basis rather than just the number.
Reading the results
The prediction interval is where this one task is likely to land. The confidence interval is where the long-run average lies. They are not interchangeable, and the second is always narrower - quoting it as if it described the task is the commonest statistical error in estimation.
The coefficient of variation is the spread as a percentage of the mean. Below about 15% your history predicts well; above about 75% you are almost certainly looking at more than one kind of task.
Outliers are flagged by the 1.5 x IQR rule and left in. Overruns are exactly what an estimate needs to allow for, so do not delete one unless you know specifically why it happened and that it cannot happen again.
The log-normal figures fit skewed data better and can never produce a negative lower bound. When the mean sits well above the median, prefer them.
Worked example: eight past actuals against a three-point guess
Eight comparable tasks took 5, 7, 6, 8, 12, 6, 7 and 9 hours. The sum is 60, so the mean is 7.5; sorted, the middle pair are both 7, so the median is 7. The squared deviations add to 34, giving a sample standard deviation of sqrt(34/7) = 2.204 hours - about 29% of the mean.
The quartiles are 6 and 8.25, so the interquartile range is 2.25 and the upper fence is 8.25 + 3.375 = 11.625. The 12-hour task is therefore an outlier - and it stays in, because it happened.
With seven degrees of freedom the two-sided 95% t value is 2.365. The prediction interval for the next task is 7.5 +/- 2.365 x 2.204 x sqrt(1 + 1/8) = 7.5 +/- 5.53, so 1.97 to 13.03 hours. The confidence interval for the mean is much narrower: 7.5 +/- 2.365 x 2.204 / sqrt(8) = 5.66 to 9.34 hours.
Committing at 80% gives 9 hours - the seventh of the eight sorted values, an actual task that actually happened. Meanwhile a three-point guess of 4, 7 and 16 gives a PERT estimate of exactly 8 hours with a standard deviation of 2. Sensible - but note that the 16-hour pessimistic case has never occurred, while the 12-hour one has.
Formulas and scoring rules
- Sample standard deviation
s = sqrt(sum (x - mean)^2 / (n - 1))The n - 1 divisor: a sample, not a population.- Prediction interval for one more task
mean +/- t(n-1) x s x sqrt(1 + 1/n)The sqrt(1 + 1/n) term is what makes this about the next task rather than about the mean. Clamped at zero.- Confidence interval for the mean
mean +/- t(n-1) x s / sqrt(n)Always narrower. It says nothing about how long one task will take.- Empirical commitment level
the value at index ceil(p x n) in the sorted historyNearest rank, so the answer is always a task that really happened.- Log-normal fit
mu, sigma of ln(x); median = exp(mu); mean = exp(mu + sigma^2/2)Percentiles from exp(mu + z x sigma). The lower bound cannot go below zero.- Three-point (PERT beta)
te = (o + 4m + p)/6; sd = (p - o)/6; band = te +/- z x sdz is 1.645, 1.960 or 2.576 for 90%, 95% and 99%.
How this differs from the PERT Project Estimator
The PERT Project Estimator schedules a network: tasks with dependencies, a critical path, and the completion date the whole project implies. This page estimates a single task in isolation, from evidence rather than from judgement, and hands back a band.
The two are not substitutes and the bands here must not be added across a project - variance does not add that way, and independence rarely holds in practice anyway. Estimate the individual task here, then take the figure into the project tool when you need a schedule.
Why a band, and why commit above the median
A single-number estimate is a probability statement with the probability left out. Half of all tasks exceed the median, so committing to the median is committing to being late half the time - which, across a team of ten, means something is late almost every week.
Committing at 80% or 90% is not padding; it is choosing the confidence you intend to deliver at, and saying so. The honest form of an estimate is "about 7 hours, 80% confident inside 9", and this page produces exactly that sentence from your own record.
The history has to be comparable
Everything here assumes the durations came from tasks like the one being estimated. Mix two kinds of work - a ten-minute config change and a two-day integration - and the spread explodes while describing neither; the page warns when the coefficient of variation goes above about 75% for exactly this reason.
It also assumes the future resembles the past. A new tool, a new team member or a changed process invalidates the history in ways no statistic can detect. When that has happened, say so and use judgement, rather than trusting a band computed from a world that no longer exists.
Limitations: what the result does not prove
- It estimates one task. It does not schedule a project, model dependencies or find a critical path - use the PERT Project Estimator for that, and do not add these bands together.
- It assumes your history is comparable and that the future resembles the past. Neither is checkable from the numbers alone.
- Small samples give wide, unstable bands. Below about five observations the intervals are indicative, and the page says so.
- It cannot account for interruptions, queueing or the difference between elapsed time and effort. If your actuals mix the two, so will the estimate.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- NIST/SEMATECH e-Handbook of Statistical Methods - Prediction intervals
- NIST/SEMATECH e-Handbook - Lognormal distribution
Frequently asked questions
How do I estimate a task from historical data?
Collect the actual durations of comparable past tasks, take the median for the typical case and a percentile - usually the 80th - for what you are prepared to commit to. Paste them here and the page adds the spread, the prediction interval and a log-normal fit for the skew that task durations almost always have.
What is the difference between a confidence interval and a prediction interval?
A confidence interval says where the long-run average lies; a prediction interval says where the next single task will land. The prediction interval is always wider, because it carries the variation of one task as well as the uncertainty in the mean. For estimating work, the prediction interval is the one you want.
How many past tasks do I need?
Five is workable, ten is comfortable, twenty makes the percentiles stable. Below five the bands are wide and move a lot with each new observation - still more honest than a single guess, but not something to present as precise.
Should I remove outliers from my history?
Usually not. An overrun that actually happened is exactly the kind of event an estimate must allow for, and removing it produces a confident, narrow, wrong band. Remove one only when you know specifically why it happened and that the cause is gone.
What confidence level should I commit at?
Higher than the median. Committing at 50% means being late half the time by construction; 80% or 90% is normal for a commitment as opposed to a forecast. The important part is saying which one you used, so nobody mistakes a forecast for a promise.
Why is the mean higher than the median in my data?
Because task durations are right-skewed: nothing finishes in less than no time, but anything can overrun. That is normal, and it is why the log-normal figures - whose median is exp(mu) rather than the arithmetic mean - usually fit better than a symmetric interval.
Can I add these estimates together for a project?
No. Variances, not standard deviations, are what add, and only when the tasks are independent - which in practice they are not, because the same person, the same tool and the same week affect them all. Use the PERT Project Estimator for a schedule.
Last reviewed by the A2Z.Tools team against the sources listed above.
