Module 5 — Time, Planning and Insight · Lesson 5.2
Estimates in the Product
Where estimates come from, what calibration does to them, and the rule about never writing back
~11 min
What you'll learn
- Get an estimate onto a task, manually or automatically
- Read the estimate-versus-actual comparison for your workspace
- Explain why calibration is applied at planning time rather than to the task
- Use a range rather than a number when committing to a date
Estimates are wrong. That is not a failure to be fixed by trying harder; it is a property of estimating work you have not done. What a good system does is measure how wrong, in which direction, and by how much — and then apply that correction where it belongs. Kavanah does exactly that, and the where matters as much as the what.
Getting an estimate
A task carries an estimate field you can fill in directly. Kavanah can also produce one automatically, drawing on the task's own content and on your workspace's history of similar work.
The automatic estimate is a starting point, not a verdict. Where you disagree with it, put in your own — your disagreement is information, and the calibration loop will find out which of you was closer.
The practical advice is to estimate at triage rather than at capture. At capture you are trying to not lose the thought; at triage you are deciding what the work is, which is when you actually know enough to guess at its size.
The calibration loop
When a task completes with both an estimate and tracked time, Kavanah has an estimate-versus-actual pair. Aggregated across many tasks, those pairs produce a calibration ratio for the workspace: how much longer things actually take than you think they will.
This is more useful than it sounds, because the ratio is usually stable even when individual estimates are wildly off. A team that consistently runs at 1.6x is a team you can plan for accurately, by multiplying. A team whose ratio swings between 0.8 and 3.0 has an estimating process that is not a process.
So the first thing to look for is not accuracy but stability. Stability is correctable; noise is not.
The rule: never write the uplift back
This is the piece of design worth understanding because it explains something that would otherwise look like a missing feature.
Kavanah applies the calibration uplift at the PLANNING layer — as a forecast used for scheduling and capacity — and never writes it back onto the task's stored estimate.
The reason is mechanical. Calibration is computed by dividing the actual by the STORED estimate. If you uplift the stored value, the next ratio measures the already-uplifted number, so it comes out closer to 1.0. Repeat that and the ratio decays to 1.0 while the underlying error is unchanged: the correction has quietly unwound itself and the numbers now say everything is fine.
So the stored estimate stays as what you actually thought. The forecast is a separate, derived number. When you see a planning date that is later than the sum of the estimates, that gap is the calibration, and it is the system telling you the truth rather than the arithmetic.
Ranges, not numbers
The most useful thing you can do with a calibrated estimate is stop treating it as a number.
An estimate distribution has a middle and a tail. Planning to the middle means you are right about half the time, which is not what anyone means when they commit to a date. Planning to the tail means quoting dates so conservative nobody believes them.
The practical version: commit externally to something near the pessimistic end, plan internally to something near the middle, and treat the gap as your buffer rather than pretending it is not there. Kavanah's planning surface will show you both; the discipline is to quote the right one to the right audience.
The theory behind this — why estimates are reliably wrong, what they are actually for, and how distributions beat point estimates — is a full module in the sibling course, Project Management with Kavanah.
Get the loop running
- 1
Estimate at triage, not at capture
Add estimates when you decide what the work is. At capture you do not know enough for the number to mean anything.
- 2
Calibration needs both halves. An estimate with no actual teaches the system nothing.
- 3
Look at your calibration ratio
The planning surface is where the uplift shows up. Look for stability first and accuracy second.
- 4
Quote the pessimistic end externally
Plan to the middle internally. The gap is your buffer, and naming it beats pretending it does not exist.
What to watch
- Calibration stability
- How much the estimate-to-actual ratio varies period to period.
- Healthy signal: Stable. A stable ratio of 2.0 is far more useful than a ratio that averages 1.1 and swings wildly.
- Estimate coverage
- Share of completed tasks that had an estimate.
- Healthy signal: High for planned work. Tasks completed with no estimate contribute nothing to calibration.
- Forecast-to-commit gap
- The difference between the calibrated forecast and the date you committed to externally.
- Healthy signal: Positive and deliberate. A committed date earlier than the forecast is a decision to be late, made in advance.
Key takeaways
- ·Estimate at triage; automatic estimates are a starting point you should disagree with when you disagree.
- ·Calibration divides actual by the STORED estimate, so the uplift must never be written back.
- ·A planning date later than the sum of estimates IS the calibration doing its job.
- ·Look for a stable ratio before an accurate one — stability is correctable, noise is not.
- ·Commit externally near the pessimistic end and plan internally near the middle.
Next: the surface where those forecasts turn into a plan — sprints, capacity, and the longer horizons.