Live data from Hacker News

Why software projects take longer than you think – a statistical model

erikbern.com

11–20 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#11
I've always thought that typically overoptimistic estimates tend to be more based on the mode. I.e. 'this is the sort of task that normally takes 1 day, so I'll estimate 1 day'. The high point on the probability curve is the most noticeable, but it's also way further to the left than either the mean or the median.

I have no data to back that up though.

Re: Why software projects take longer than you think – a statistical model

#12
post #6

This is why I like 3 point estimation[1] - if you have optimistic, expected and pessimistic estimates for each task you can pull out which points are high risk. Using a single estimate can't give you that insight. [1] https://en.wikipedia.org/wiki/Three-point_estimation

manager: "thanks for the optimistic estimate!"

Sure, in the same way a bad manager will say "No, that's too high, I'm going to reduce your estimate" if you use a single number. Bad managers are a thing. Make sure you get a good one.

Re: Why software projects take longer than you think – a statistical model

#14
post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

A professor of mine at university taught us the same thing. It's one of the most valuable things I learned and it is uncannily accurate. Even after 30 years in industry I still fall back on this formula with great results.

Sadly, managers want to believe that you put more effort into estimating deadlines so I'll just whip up a gannt chart retroactively based on the 2/20 rule and they're happy.

Re: Why software projects take longer than you think – a statistical model

#16
post #4

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

Yeah, that's the same reason to use pseudoscience, it's a longer word with "science" in it, which means - more science!

Re: Why software projects take longer than you think – a statistical model

#17
post #7
post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

An approach that gives very similar results to yours but is more scientific is to multiply the initial estimates by e (2.718). Or, if you're conservative, then by pi.

The above approach uses the factor 2.2. Why would your factors be any better?

Re: Why software projects take longer than you think – a statistical model

#18
US navy has developed something similar with beta statistical distribution. You estimate "Optimistic", "Most likely" and "Pessimistic" time estimates for each task in the project and then use beta distribution on it. Some tasks take way longer than estimated.

Here is the link to the time estimation described above with Beta distribution. https://www.isixsigma.com/methodology/project-management/bet...

Re: Why software projects take longer than you think – a statistical model

#20
Something I’ve been trying is estimating for the time in which I’m 80% sure I can finish something. I end up racing ahead of estimates most of the time because they are too high, but then some times I’ll find something that is a bit more complicated than expected and it takes a little longer. Overall this seems to balance out, but also have a lot more predictability, it’s easier to predict at any given time what I might be working on. This has been pretty important on my team where I’ve been doing API work for some iOS developers to use.
Post reply on HN