Why software projects take longer than you think – a statistical model
1–10 of 324 posts
Re: Why software projects take longer than you think – a statistical model
#2Yes, this is a thesis I've brought up quite some times in relation to sprint planning. The odd misjudgment having a strong influence on the total estimate biases upwards, not downwards.
Re: Why software projects take longer than you think – a statistical model
#3One take away is for sprint planning - if there is a reasonable amount of uncertainty on a task, take it out, either break it down or do some investigation, and bring it back next time.
You don't want a σ=2 task messing up your sprint!
Re: Why software projects take longer than you think – a statistical model
#4I 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.
Re: Why software projects take longer than you think – a statistical model
#5My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.
Re: Why software projects take longer than you think – a statistical model
#6This 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.
Re: Why software projects take longer than you think – a statistical model
#7My 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.
Re: Why software projects take longer than you think – a statistical model
#8My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.
Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.
Re: Why software projects take longer than you think – a statistical model
#9This 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!"
Re: Why software projects take longer than you think – a statistical model
#10My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.
Or you could just multiply by 2.4 ...
I used to do 2.5, I read somewhere 2.5 was fairly common