Probably many sequences of powers works, and many bases: base^0.5, base^1, base^1.5, base^2, ...
eg., 4^0.5, 4^1, 4^1.5, 4^2, 4^2.5 = [2, 4, 8, 16, 32]
If the estimate is 3days, then the scope is: [3, 6, 12, 24, 48, 96]
Now we have a "semi-principled" set of numbers to choose from, the estimator applies their domain knowledge to select the relevant scales: 3 to 24 say, based on "how big the project could be".
ie., is it both possibly a small change in one area (to a table), and possibly "reworking the foundations of the house" -- if so, you have the small-scale starter number, and you can dial up using this sequence to whatever magnification suits.
Probably with base pi, and sequence (0.5, 1, 2) we capture the three most relevant scales for most properly discrete software tasks. That's essentially conincidental, in that i'm sure a (2 to 4) base with several sequences would wokr.
while I can understand that this is a controversial assumption, I'm not the first one to make it. Referring to numerology seems a bit odd?
I'm really looking for a proper way here, I'm quite a rational person, so numerology is not really my cup of tea TBH.
"converting from a standard uniform distribution to a Gaussian distribution" as you described does not make any sense at all. If you replace an initial assumption of a degenerate distribution with a Gaussian, as you seem to be doing, you replace a no-uncertainty (stdev=0) assumption with some uncertainty (so the uncertainty blow-up is infinite), but it doesn't affect point estimates such as the mean or median, unless you make separate assumptions about that. There is nothing in your story that leads to multiplying some initial time estimate by sqrt(pi). The only tenuous connection with sqrt(pi) in the whole story is that the Gaussian integral happens to be sqrt(pi). There are some deep mathematical reasons for that, which has to do with polar coordinates transformations. But it has nothing to do with adjusting uncertainties or best estimates.
If that were your actual assumption, you should measure the variance of the difference between your estimate and the actual time taken, use that to determine a confidence interval (e.g. 95% of the time, the additional delay is less than x) and then add it to your estimate.
Here is a good example video of what I am alluding to: https://www.youtube.com/watch?v=9CgOthUUdw4
Maybe I should refine my blog post or include the video in the explanation?
What I found was most people over/under estimate things. They also tend to do it consistently at the same rate. Typically they have a scaling factor you can use. Around 3 seems to be the sweet spot for most people. You could just as easily use 3.1 or 3.2 and get a similar answer. I usually go for 3 because I can do that in my head without a calculator.