4 ms·

The best book I have read on software estimation is: http://www.stevemcconnell.com/est.htm http://www.stevemcconnell.com/est.htm My best short advice would be:

by zby 9y ago

The best book I have read on software estimation is: http://www.stevemcconnell.com/est.htm http://www.stevemcconnell.com/est.htm My best short advice would be: always try to make an as detailed as possible list of tasks and estimate them independently - this way it is harder to forget about some details and when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other.

dagw 9y ago
when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other. Not in my experience. Under-estimate errors are basically always much smaller than over-estimate errors. Unknown factors that can dramatically speed up a projects are much fewer than unknown factors that can dramatically slow down a project. I mean if nothing else a 4 week task can, at best, be delivered 4 weeks early, but there is no upper limit to how late it can be.
- jakubp 9y ago
  This. It strikes me as odd these days when managers and engineers assume symmetrical distribution of time required to complete tasks. This is not only relevant in software development: in my experience, the larger the organisation or set of people/departments involved in any kind of work, the heavier the time distribution is on the "late" side.
  - slavik81 9y ago
    That was one of the things that burned us once we finally got our task estimates accurate. Most tasks would be finished in about the time estimated, but one would be off by a factor of ten and blow the iteration. We discovered that for estimates to be accurate overall, most tasks need to be finished early. It's counterintuitive, but it's directly the result of that asymmetric distribution.
  - zby 9y ago
    If you are systematically under-estimating (as most novice estimators - people tend to be optimistic) - then you can calculate how much you usually under-estimate and then adjust.
ozim 9y ago
I never have time to make detailed list and I never get enough good specification from sales/business. Get 5-7 people in the room for planning meeting and try to do detailed list of tasks. For one hour you can tackle maybe one story or one and a half. I have backlog with 10-15 stories so 10hrs with 5 people is insane amount of money and you cannot do it in one day so it will take two weeks (1hr per day if all people have light schedule). In my experience such approach always ended up with complete disappointment, budget burned on arguments over nonsense.
aptwebapps 9y ago
I got this book recently because I loved Code Complete. I've read the first half, haven't had time to finish, but the key take away for me is that nothing really beats historical data. In fact, he showed that even breaking down things into tiny details is not much help without historical data to base estimates on, or maybe I'm misremembering.

by zby 9y ago

dagw 9y ago

when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other. Not in my experience. Under-estimate errors are basically always much smaller than over-estimate errors. Unknown factors that can dramatically speed up a projects are much fewer than unknown factors that can dramatically slow down a project. I mean if nothing else a 4 week task can, at best, be delivered 4 weeks early, but there is no upper limit to how late it can be.

jakubp 9y ago
This. It strikes me as odd these days when managers and engineers assume symmetrical distribution of time required to complete tasks. This is not only relevant in software development: in my experience, the larger the organisation or set of people/departments involved in any kind of work, the heavier the time distribution is on the "late" side.
- slavik81 9y ago
  That was one of the things that burned us once we finally got our task estimates accurate. Most tasks would be finished in about the time estimated, but one would be off by a factor of ten and blow the iteration. We discovered that for estimates to be accurate overall, most tasks need to be finished early. It's counterintuitive, but it's directly the result of that asymmetric distribution.
- zby 9y ago
  If you are systematically under-estimating (as most novice estimators - people tend to be optimistic) - then you can calculate how much you usually under-estimate and then adjust.

ozim 9y ago

I never have time to make detailed list and I never get enough good specification from sales/business. Get 5-7 people in the room for planning meeting and try to do detailed list of tasks. For one hour you can tackle maybe one story or one and a half. I have backlog with 10-15 stories so 10hrs with 5 people is insane amount of money and you cannot do it in one day so it will take two weeks (1hr per day if all people have light schedule). In my experience such approach always ended up with complete disappointment, budget burned on arguments over nonsense.

aptwebapps 9y ago

I got this book recently because I loved Code Complete. I've read the first half, haven't had time to finish, but the key take away for me is that nothing really beats historical data. In fact, he showed that even breaking down things into tiny details is not much help without historical data to base estimates on, or maybe I'm misremembering.