Estimating in ranges

A single estimate hides the most useful part of what the owner knows: how sure they are. Ask for three numbers per task instead: optimistic (if everything goes well), most likely and pessimistic (if the known troubles happen). This isn't a way to dodge a commitment; it is more information, not less.

The width of the range is the signal. A narrow range says the work is well understood. A wide one says something specific is still unknown, and it points you at the task to ask about. At Klasna, writing the 40 test questions is estimated at 3, 5 and 13 days: ten days of spread on a five-day task. Vira explains why: each question needs a worked solution and a diagram, and the diagrams come from an outside illustrator.

So the first move with a wide range is a question, "what could push it to 13?", not an accusation of padding and not a demand for one number.

Three numbers are easier to plan with when you summarize them. The expected value weights the most likely case four times and each extreme once: E = (O + 4M + P) ÷ 6.

For the test questions (3, 5, 13 days): (3 + 4 × 5 + 13) ÷ 6 = 36 ÷ 6 = 6 days. Notice that 6 is more than the most likely 5. That is typical of project work: things rarely go three days better than planned, but they often go a week worse. The bad side is longer, so the expected value moves toward it.

This is why planning on the most likely value alone keeps coming out late. The expected value already prices in the long bad side; the most likely value ignores it.

The expected value tells you where the middle is; the standard deviation tells you how far the real result may wander from it. For a three-point estimate it is simply a sixth of the distance between the extremes: σ = (P − O) ÷ 6. The most likely value doesn't enter it.

For Danylo's trial with 20 learners and the fixes (2, 3 and 10 days): σ = (10 − 2) ÷ 6 ≈ 1.33 days, around an expected value of (2 + 12 + 10) ÷ 6 = 4 days. For the test questions (3, 5, 13): σ ≈ 1.67 days.

Keep both numbers together. An average alone hides how late the work can be: two tasks with the same expected value of 4 days can have very different risk if one runs from 3 to 5 and the other from 1 to 13.

For tasks that run one after another, expected values add up: the test's three tasks give 6 + 6 + 4 = 16 days. Spreads don't add the same way.

The standard deviation of one task is a sixth of the distance between its extremes: σ = (P − O) ÷ 6. To combine several, square each standard deviation to get its variance, add the variances, then take the square root. For the test: 1.67² + 0.67² + 1.33² ≈ 2.78 + 0.44 + 1.78 = 5.0, and √5 ≈ 2.24 days.

The tempting shortcut, 1.67 + 0.67 + 1.33 ≈ 3.67, pretends every task hits its bad day at the same time. In practice a bad week on one task is often offset by a good one on another, so a chain is more predictable, relative to its size, than each task alone. And 5.0 itself is the variance, not the spread: always take the root.

Adding variances, as with the test's 2.78 + 0.44 + 1.78, rests on one condition: the tasks must be independent. The rule works because a bad week on one task is usually offset by a good week on another, so they rarely all go wrong together.

A shared cause breaks that. At Klasna the outside illustrator draws the diagrams for the test questions; if he is late, the questions slip, the trial starts late and the fixes slip too. The three tasks no longer wander separately: one event moves all of them in the same direction, and the real spread is wider than √5.

Don't hide such a cause inside the task ranges. Pull it out and treat it as one risk with its own owner and a plan, for example agreeing a delivery date with the illustrator or starting with the questions that need no diagram.

A range becomes a date only when you say how sure you need to be. With the expected value and the standard deviation, a common rule is two standard deviations either side: under the usual bell-shaped assumption the result lands inside that range about 19 times in 20.

For the test: 16 ± 2 × 2.24, so about 11.5 to 20.5 working days. The three points on that range mean different things. 16 days is roughly even odds: as likely late as early. About 21 days is a date you can be fairly sure of, the one to give for anything other work depends on, like Leo's marketing plan. 14 days, the sum of the most likely values, sits below the expected value, so with a long bad side on two tasks it is missed more often than met.

The number you promise depends on what breaks if you're late.

The same piece of work can be described by several true numbers, and the trouble starts when the listener hears a different promise from the one you meant. So say which number you are giving.

The expected value (16 days for the test) is for planning the middle: half the time you'll be earlier, half later. The top of the range (about 21 days) is for anything others build on, such as a marketing launch or a tutor schedule. The sum of the most likely values (14 days) is an optimistic figure, not a plan. The width of one task's range (3 to 13 days for the questions) isn't a date at all: it points at where the risk sits and what to ask about.

A good estimate message therefore carries three things: the expected value, the date you're fairly sure of, and the cause of the spread.

An estimate is a forecast made with what you know today, so it should change as you learn. Halfway through, re-estimate what is left and send the new range with its cause, not "on track" and not the old number out of pride. As unknowns get answered, ranges narrow; that narrowing is progress too. When a range widens, that is news the sponsor needs now, while there is still time to adjust.

Sometimes the honest answer is Vira's: "I'll know in a week". That is a fine estimate as well: a date by which you'll have a better one. What isn't fine is a number nobody believes.

A useful update to Leo: "Questions are harder than planned; the test is now 17 to 23 working days, expected 19. I'll update on Friday after the diagram review."

How it fits together: a range, its expected value and spread, and a date chosen by confidence make an honest estimate. The next lesson checks estimates against how earlier Klasna launches really went and replaces padding with one shared buffer.