A single number is a promise. A range is information. When a client asks how long a feature will take and we answer “six weeks”, we have thrown away everything we actually know about the problem and replaced it with false confidence.
So we quote four to nine weeks instead, and we say what sits at each end. The optimistic number assumes the third-party API behaves as documented and the client can answer questions within a day. The pessimistic number assumes neither.
What actually moves the number
In our experience three things dominate the spread, and none of them is how fast anyone types.
The first is integration with systems we do not control. A payment provider with clean sandbox credentials is a week. The same provider with a certification process and a support queue is a month.
The second is decision latency on the client side. Not the number of decisions, the time each one waits. A project where the person with authority joins the sprint review finishes much closer to the optimistic end.
The third is how much of the existing system we have to understand before we can safely change it. Undocumented legacy code is not slow to write against, it is slow to read.
Narrowing it honestly
After two sprints the range usually collapses on its own, because by then the unknowns have become known. We re-quote at that point rather than defending the original guess. An estimate that never changes is not accurate, it is just unexamined.
