5 ms·

I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is

I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is to give an estimate the less time they want you to spend researching the work. To increase the accuracy of an estimate, you need to do more research and if you take that to its logical conclusion then the best estimate is given after the work is completed. So there is some area in between of extremely inaccurate guess with little effort to actually doing the work and knowing the time it took. It's best to accept that estimates are near useless (unless you want to spend a lot of time basically doing waterfall to come up with requirements/design/etc...) and instead just try to find out how to chop up the work into smaller pieces that each deliver value and plan how the feature will be delivered. This way the team can be focused on actually getting value out the door instead of spending time doing a futile exercise (estimating).

LoSboccacc 8y ago
I’ve got to do a lot of contract software work back in the day and was the one working first draft requirements with clients before the actual contract. It was common to spend a week into planning for every six man/month of project Using that as ballpark we never got an estimate having more than 10% error. Anectodal, I know, but without that kind of effort one is not doing an estimate is doing a guess. That also why I don’t like the agile approach of piling up efforts and then use actual time to tune speed hoping the inaccuracies will level off one another. It just feel like a sequence of dice rolls hoping you don’t end up at the far tail of the gaussian.
- andrewflnr 8y ago
  > It just feel like a sequence of dice rolls hoping you don’t end up at the far tail of the gaussian. That's exactly, precisely what it is, by design AFAICT. The thing about gaussians is, what with the central limit theorem and all, you provably don't end up on their tail very often. That said, gathering a bunch more data can make your gaussian even narrower. I think you and (platonically ideal) Agile are just at different spots on the same spectrum of risk tolerance.
amarkov 8y ago
High level estimates aren’t optional for most development. Customers waiting for an important feature won’t take “ it’ll come when it comes, estimates aren’t real” as an answer. You can skip low level estimates, but the consequence of that is that high level timelines are uninformed by them. That’s how you end up in the archetypal situation where all the engineers know a project will slip while their managers report it’s right on track.
- bsandert 8y ago
  In my experience, knowing when work on some functionality will _start_ plus a rough estimate on effort (talking hours/days/weeks level) is quite acceptable for most stakeholders. It is also far easier to provide, and less likely to be off by an order of magnitude, which some low-level estimates may suffer from.
- giulianob 8y ago
  My point is you need to balance the effort you're putting into your estimates vs getting work done. Customers also won't be happy when you give them a date and don't meet it. Honesty is important too.
hinkley 8y ago
“Bitesized” is the only estimate that matters.

LoSboccacc 8y ago

I’ve got to do a lot of contract software work back in the day and was the one working first draft requirements with clients before the actual contract. It was common to spend a week into planning for every six man/month of project Using that as ballpark we never got an estimate having more than 10% error. Anectodal, I know, but without that kind of effort one is not doing an estimate is doing a guess. That also why I don’t like the agile approach of piling up efforts and then use actual time to tune speed hoping the inaccuracies will level off one another. It just feel like a sequence of dice rolls hoping you don’t end up at the far tail of the gaussian.

andrewflnr 8y ago
> It just feel like a sequence of dice rolls hoping you don’t end up at the far tail of the gaussian. That's exactly, precisely what it is, by design AFAICT. The thing about gaussians is, what with the central limit theorem and all, you provably don't end up on their tail very often. That said, gathering a bunch more data can make your gaussian even narrower. I think you and (platonically ideal) Agile are just at different spots on the same spectrum of risk tolerance.

amarkov 8y ago

High level estimates aren’t optional for most development. Customers waiting for an important feature won’t take “ it’ll come when it comes, estimates aren’t real” as an answer. You can skip low level estimates, but the consequence of that is that high level timelines are uninformed by them. That’s how you end up in the archetypal situation where all the engineers know a project will slip while their managers report it’s right on track.

bsandert 8y ago
In my experience, knowing when work on some functionality will _start_ plus a rough estimate on effort (talking hours/days/weeks level) is quite acceptable for most stakeholders. It is also far easier to provide, and less likely to be off by an order of magnitude, which some low-level estimates may suffer from.
giulianob 8y ago
My point is you need to balance the effort you're putting into your estimates vs getting work done. Customers also won't be happy when you give them a date and don't meet it. Honesty is important too.

hinkley 8y ago

“Bitesized” is the only estimate that matters.