4 ms·

1. Write a list of the things you need to do. Be detailed. The more detail, the better. 2. Estimate how long you think each will take, knowing it always takes

by lbrandy 18y ago

1. Write a list of the things you need to do. Be detailed. The more detail, the better. 2. Estimate how long you think each will take, knowing it always takes longer than you think. 3. Realize it always takes longer than you think, and revise your list. 4. Double everything. 5. Round up. 6. Add it all up, walk to towards your bosses office and/or call the client. 7. In a last second panic realization that it always takes longer than you think, double it again. In all seriousness, you will get better over time, namely after you do this many times. The only "secret" to the process is write down a detailed list of the things that must get done. Alot of people tend to clump up alot of the endgame details as "polishing" and that results in the 90/10 rule taking full effect (that the last 10% of the work takes 90% of the time) because things like UI testing, inserting the logo, doing the install script, etc, etc, take forever and a day.

ynniv 18y ago
At the risk of being a metoo, it should be emphasized that things need to be doubled. I'm not sure why, but I constantly find that things take twice as long as I expect, even after accounting for the fact that things need to be doubled. It sometimes helps to keep doubling it until it seems funny that it could take so long, and then step back once. ie, "Writing a parser will take a week. Two weeks. Four weeks... weeeeell, probably not four weeks - two weeks it is." I also like to front-load things that I'm uncertain about, as playing catch-up near your deadline is easier when you have (hopefully over-estimated) well known tasks remaining.
- thalur 18y ago
  I think the doubling comes from the fact that initial estimates are always that it would take x weeks if you were to work flat out 100% of the time. As this is incredibly unlikely to happen, you have to increase the estimate to take into account "overheads" (such as posting here...). I like your "double until it's silly then go back a step" idea; it seems like a good way to get quick estimates. I try to take into account how accurate my estimates will be: if a sub-task is something I've done alot, I stick with my estimate; if it's something where I think there's a risk of it going wrong I add more time (keeping a note of the estimate and the risk time separately - it makes project managers think you know what you're doing!). I then add them all up, divide by 0.7 (roughly how efficiently I convert booked hours into directly worked hours - the rest is email and meetings etc.). Also, any task where you have to write code that works with someone else's code, I double the estimate.
- jdavid 18y ago
  it sounds like what you are saying is the first estimate is the optimist in us, and until it seems 'funny' that it should take so long, you are giving it a test against the pessimist in you. as entrepreneurs, and creators we probably always 'believe' that something is doable, hence the optimism.
thomanil 18y ago
What he said, apart from a few differences that I've found works for me (YMMV): 1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating. 2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz! 3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game". 4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.) 5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week. 6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors". 7. By this point you have a rough idea of when you will be done... in an ideal world. :) Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)
JesseAldridge 18y ago
8. Realize that your estimate is ridiculously huge and anyone who sees it will think you're screwing with them. 9. Rationalize cutting it down. 10. Kick yourself as you struggle to meet impossible deadlines.

by lbrandy 18y ago

ynniv 18y ago

At the risk of being a metoo, it should be emphasized that things need to be doubled. I'm not sure why, but I constantly find that things take twice as long as I expect, even after accounting for the fact that things need to be doubled. It sometimes helps to keep doubling it until it seems funny that it could take so long, and then step back once. ie, "Writing a parser will take a week. Two weeks. Four weeks... weeeeell, probably not four weeks - two weeks it is." I also like to front-load things that I'm uncertain about, as playing catch-up near your deadline is easier when you have (hopefully over-estimated) well known tasks remaining.

thalur 18y ago
I think the doubling comes from the fact that initial estimates are always that it would take x weeks if you were to work flat out 100% of the time. As this is incredibly unlikely to happen, you have to increase the estimate to take into account "overheads" (such as posting here...). I like your "double until it's silly then go back a step" idea; it seems like a good way to get quick estimates. I try to take into account how accurate my estimates will be: if a sub-task is something I've done alot, I stick with my estimate; if it's something where I think there's a risk of it going wrong I add more time (keeping a note of the estimate and the risk time separately - it makes project managers think you know what you're doing!). I then add them all up, divide by 0.7 (roughly how efficiently I convert booked hours into directly worked hours - the rest is email and meetings etc.). Also, any task where you have to write code that works with someone else's code, I double the estimate.
jdavid 18y ago
it sounds like what you are saying is the first estimate is the optimist in us, and until it seems 'funny' that it should take so long, you are giving it a test against the pessimist in you. as entrepreneurs, and creators we probably always 'believe' that something is doable, hence the optimism.

thomanil 18y ago

What he said, apart from a few differences that I've found works for me (YMMV): 1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating. 2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz! 3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game". 4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.) 5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week. 6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors". 7. By this point you have a rough idea of when you will be done... in an ideal world. :) Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)

JesseAldridge 18y ago

8. Realize that your estimate is ridiculously huge and anyone who sees it will think you're screwing with them. 9. Rationalize cutting it down. 10. Kick yourself as you struggle to meet impossible deadlines.