05Size first, duration later
The usual way to estimate is to ask "how long will this take?". It blends two different questions: how big is the work, and how fast does this team work? Agile planning separates them, because each is answered better on its own.
Why relative sizing
People are poor at estimating durations and good at comparing. Few developers can say reliably that a piece of work will take eleven days. Most can say that it is about twice as big as another piece they understand. So the team sizes work by comparison, in abstract units usually called story points, using a small scale with growing gaps (1, 2, 3, 5, 8, 13). The gaps are deliberate: the bigger the item, the less precise any estimate can be, and arguing over 9 or 10 is false precision.
Duration is then derived, not guessed. The team measures how many points it actually completes per sprint, its velocity, and the forecast follows from dividing the remaining size by that measured speed. Size is a judgement; speed is an observation. Keeping them apart means that when the forecast is wrong, you can tell which of the two was wrong.
The conversation is worth more than the number
Teams often size together, each person revealing an estimate at the same time, so nobody anchors on the first voice heard. The most useful moment is when estimates differ widely. If one developer says 3 and another says 13 for the same story, they understand it differently, and that misunderstanding is far more valuable to discover than any number.
In the BECS example, "record a whole blood donation for a first-time donor" and "handle a confirmed positive test result" may look similar on a backlog. Sizing them side by side quickly shows that the second one touches donor eligibility, quarantine of components and traceability. The conversation reveals the work, not just its size.
How sizing goes wrong
- Velocity used as a target. Once velocity is rewarded, points inflate and the forecast loses its meaning. Velocity is a calibration for one team, never a performance measure or a comparison between teams.
- Points converted back into hours. "One point equals four hours" brings back exactly the guesswork relative sizing was meant to remove.
- Estimates treated as commitments. When a forecast becomes a promise, people pad their estimates, and the plan stops carrying information.
Section takeaways
- Estimate size by comparison, and derive duration from measured speed.
- Sizing conversations reveal misunderstandings; that is their main value.
- Velocity serves forecasting only. Used as a target, it destroys the forecast it was meant to support.