How am I supposed to know how many days something will take? [closed]

Answer 1

I'd do two things:

1. Estimate based on how long it took you to do the last task of similar complexity - the "yesterday's weather" technique.
2. Give a range estimate when appropriate - "If things go well, two days. If things are really bad, it could be two months." While that's an extreme range for the estimate, there are tasks where that's about as accurate as you can be. If you give a range, be sure to also give reasons why that range exists.

Answer 2

There is also a difference between

• time needed to complete a task (which you should learn to estimate when you acquire experience)
• and delay : time to complete that task, plus time to do other things that are more urgent

About the estimation of time needed to do something :

• the first time you do something, it's hard to have any idea of how long it will take to complete it
• but, as time goes by, you will have done more and more different stuff ; and, each time, you'll remember how long it took you.

After a while, when asked "how long will it take you do do that ?", you'll be able to think :

• "that" is quite similar to the other thing i did on project X, and that other other thing I did on project Y
• I spent 8 days doing it on project X, and 6 days doing it on project Y ; but it was much easier on Y, because I already had some idea of how to do it (already done it on X)
• so, on this new project, it shouldn't take more time than on project Y
• actually, I'm even better now, more experienced... So it should take about 5 days
• and to not put too much pressure on yourself, and keep some margin of error, you say 6 days, or 6 days and a half to your boss.
• and, in his head, he will add another day ^^ (or, if he his the kind of guy who count 4 when he hears 6, just tell him 8, and he'll understand 6 ^^ )

As time passes, you'll get better and better at this ; and, in the end, you'll probably become able to :

• estimate how long it should take you to do something you never did before
• estimate how long it should take for another developper to do it
  • and this, both for an experienced developper,
  • or for a beginner
  • or just for one specific guy

Ho, and I forgot : I generally add about 15% of the "development time" for tests and corrections of bugs, btw -- it's a standard rate, for projects I worked on, and generally quite accurate (of course, for a beginner, who will probably create more bugs, you'll add a bit more ; for an experienced developper, a bit less).

Yes, of course, sometimes, you'll be totally wrong ; it happens, that's it : everyone makes mistakes once in a while :-)

About delay : well, I generally tell my boss "it should take me X days if I don't have to do something else" ; then, if my boss tells me to do something else for 2 days in the middle of my task, it's "his fault" ^^

When working alone on a project, or being "my own boss", I generally know how much time I have to spend on "other stuff".
ON a project I worked some time ago, I used to tell the client : "I need 5 days to do this, but considering I generally spend half of my time doing not planned stuff, let's consider it'll take me 10 days total" -- after a while, you get used to count like this ^^

Answer 3

One way to help you get better at this is to track your original estimate (shoot in the dark if you have to at first) then track how long it actually took you. You might even want to estimate how "hard" it was to do and how hard you thought it was going to be originally say on a scale of 1 to 10.

Do this for a while and you might start seeing a pattern and even start to understand how you good / bad (relative term) your estimates are.

As time goes on use these to help you rethink your estimates. For example, the last few times I have estimated a 5 day task that was of medium difficulty ( say a 5 out of 10) I have been off by an average of 5 days.

With that I am going to estimate 10 days on this one and see what happens. :)

Continually redo this exercise and you will start to get a better handle on this.

Oh and yes, as already mentioned estimation is hard and there are alot of resources out there but nothing like practice or a really good mentor. :)

Answer 4

From my experience (having been both on the manager's and the associate side) I know that most managers do not report the estimate given by their employees up to the next level. Instead they go by their own gut feeling + knowledge of the external constraints.

When manager asks for an estimate, he/she often cares less about the estimate value itself as much as about associate going through the analysis and figuring out subtasks, major gaps, dependencies, etc. In other words, asking for the estimate is often a trick the management employs to get the employee going. In this case the estimate value is just a dependency injection mechanism to force the employee to do the analysis.

Of course tricky managers also tend to remember the estimate value, especially if it was an underestimate and use it to control the urgency level on the project.