What are you estimating? The time to manufacture something?
This has been solved for decades in Software Development.
Here is the process:
- Copy the file/folder to the Clients Machine.
Estimated time 5 minutes (give or take 2 weeks depending on delivery mechanism and size).
Given that manufacture is so simple, you are probably interested in estimating the time for designing.
Design can be split into two parts.
Generally speaking Arrangement is the easier part, given a client that is willing to co-operate.
Simply go out and find out that which is not known, then spend time to know it.
This is frankly impossible to estimate. As an observation take a look at predictions for: Fusion Power, Cancer Cures, Mars Colonisation, Self-programming Computers, etc...
When there exists something unknown, you simply cannot guess its size. The only proxy you have are any past experiences in the area.
Those past experiences are probably skewed representations themselves. If they shared a lot in common with your goal then you are not conducting Research but Arrangement.
Given a box full of previous designs re-arrange the ideas/components to produce what was asked for.
The benefit here is that the components/ideas have already been designed. If work has to occur to create/alter them, there already exists a well established methodology for their construction/alteration. (If not then this is Research.)
Given that there is a well known methodology, it is estimable based on the time taken by previous endeavours to produce/alter those components in the same way.
What this means is that design is a balancing act of Researching the new knowledge, and Arranging that newly acquired knowledge with an older box of designs.
The problem is that most software projects are not in the later category very often. Which means a lack of standardised methods and estimations.
Those that are in this later category have generally speaking already been turned into commodity components. The estimated time to obtain these is approximately 5 minutes. (Obviously not for the first usage, but as the component is reused within the team).
What that leaves is the unknown.
The unknown, is by definition unknown.
So obtaining an accurate (or even proximally accurate) estimation is simply impossible.
However just because the unknown does not blink, does not mean that we cannot estimate our own lack of knowledge with regard to what is known.
Humans are logarithmic machines by nature, which means we are really sensitive to small differences at close to known, but crappy at handling similar discernment on larger scales.
What this means is that when the task, and the unknown element are small humans are great are judging it. These tasks are essentially arrangement.
Unfortunately a task which is Huge, or a task that is very uncertain, do not fit into comprehension (by definition). To make it fit humans abstract it down. This means that what appears to be a little increase in size/uncertainty translates into a huge difference in actual effort needed. In short Research.
This is why the series needs to be exponential. Its simply the most practical crutch to translate human logarithmic judgement to something vaguely linear.
As to which series to use. That is a mater of taste, and team preference. Which crutch best fits the teams own logarithmic distribution.