3 ms·
Estimating time for a task is it's own skill. And, of course, the danger is in the task being insufficiently specified, leading to unknowns. Cook lunch, estima
by bruce511 3y ago
Estimating time for a task is it's own skill. And, of course, the danger is in the task being insufficiently specified, leading to unknowns.
Cook lunch, estimate 30 minutes. Task starts, oh wait, cupboard is bare, need to go shopping.
Over a long career I've found that you do the best estimate you can with the information provided. Then multiply by 4. Sounds extreme, but you're still likely to be short a bit.
Equally, for estimates, I like to first estimate the number of data tables. That's a good factor to bring in to the rest. A system with 10 tables, 100 tables, 200 tables and so on "magnifies" the task list.
"Build reports" has a proportionate number. 10 tables might mean 5 reports. 100 tables might mean 50.
Building reports might be easy, but the number of them means time is needed.
- XorNot 3y agoThis is close to my rule - whatever I think, multiply by 3. Then multiply by 3 if it includes any amount of "get another team, under a different manager, to do something". It's been accurate more times then I care to think.
- 8n4vidtmkvmk 3y agoMy current project estimate is 1 year. I'm afraid if I need to multiply that by 3.
- Ma8ee 3y ago> Over a long career I've found that you do the best estimate you can with the information provided. Then multiply by 4. Sounds extreme, but you're still likely to be short a bit. Me myself rely on Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.