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

Question

I am a PHP developer, and I often have no idea in terms of days--let alone hours--how long something will take me at work. I am often writing new stuff, merging it with old legacy crap. I can tell my boss what week I will likely have something done--and maybe what half of what week--but I how in the world am I to know specifically what day something will be done? Isn't that a bit unrealistic, considering that bugs and other unknowns often arise and eat time? I can only minimize these things so much...

I am thinking of saying the following:

"Look, i understand that me saying "tomorrow! tomorrow!" is not helpful. The best I can do for you on many things I'll work on is tell you what half of a given week I will likely have it finished. and if it looks like I can possibly have it done by Friday of the given week, then we better move to the next week."

Answer 1

This article is a good description of pretty much the only way to know how long something will take: http://www.joelonsoftware.com/items/2007/10/26.html

Answer 2

Time estimation is hard.

But the times when I've done this well all have a couple things in common:

1.) I received very good and complete requirements for the project. This is important and you should ask the tough questions to make sure that the requirements really are as complete as possible.

2.) I broke the project down into sections, wrote each section on a white board, and then estimated the time for completion for each section individually. I had the rest of my team contribute as I do this so I don't forget anything. This seems so simple, but it works so well. I think it allows you to be more realistic by reducing the possibility of overlooking a part of the project that may be time consuming. If you can write down and plan out the project at a granular level like this it'll help immensely.

During this whole time estimation process you may even gain a better understanding of the project and what needs to be done. That can prevent mistakes, writing & re-writing code, etc. And that's good for everybody.

Answer 3

Go with your hunch and then add 50% time. You'll meet the deadlines, won't stress yourself, your boss will see quality code over fast code and you'll probably be faster than expected once in a while. Everybody wins :)

Answer 4

Better estimates come from experience.

You could also employ the Function Point Analysis method to get a good starting point. Then, give your project manager regular updates. Thus, on Friday when the project needs to slip into next week, your project manager won't be surprised.

Answer 5

The best advice I can give is to break down a task into smaller pieces then estimate those. Maybe attach a "confidence" percent to each sub-task to calculate an optimistic and pessimistic range. That way when your boss says "5-8 days? That doesn't help me at all, where are you coming up with these numbers!?!?" you just show him your breakdown and you have justification. A competent manager should put your butt on the line for what you commit to, not what you digress to be bullied into committing to.

Answer 6

If you can, find another job. Your boss seems to have no idea about project management, resource management and software development.

In general, all you can give is estimates. Your estimates will get better with experience (for the most part, you'll estimate far more effort than you do today). And - as any sw developer knows, there's always an option of hitting some stupid issue which will take 90% or even more of actual effort (and hugely increase development time).

Answer 7

I generally say it will take 3-4 times longer than what I really think. For instance, if I know I can build something in two days, I'll say a week or so.

That way if you finish well below your guesstimated time, you will look like a hero! :P

Answer 8

Past experience and historical data often work best for providing estimates. If you've dealt with similar code/issues before use the historical data to predict future tasks. Of course if you're dealing with something new or entirely unknown, then it's harder to provide accurate estimates. Of course they are 'estimates' which is an educated guess as to when things will be done.

Answer 9

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 10

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 11

Some thoughts about estimation:

• Estimates are different than commitments. They are a best guess using available information about effort (not time) that a body of work may take.
• Estimates are not a single number - you should really think of estimate as either a range (lower/upper bound) or a value and a confidence factor.
• Estimates have a margin of error - to reduce this margin you generally need to spend more time performing analysis and evaluation. There is a point at which the effort to produce an extremely accurate estimate will begin to approach the effort of the task itself.
• Producing a reliable estimate based on vaguely defined body of work is extremely challenging. High margins of error should be expected in such circumstances.
• When estimating a task, the best guidepost is experience with similar tasks in the past.
• If historic information isn't available (either because the work effort is unique or you don't track this history) - the best you can do is decompose the task into the finest level of work that makes sense.
• Try to ask other people in your organization who may have experience with the system or codebase to review your estimates.

Answer 12

• Being asked to quote in days is ridiculous, the best you can do is estimate.
• Try at all costs to avoid being coerced into giving an outright guess, you will almost certainly be wrong. Buying some time to make a better estimate is always a better idea.
• If you are dealing with changing or interfacing with some code you have no previous experience with, then try and give an estimate of how long it will take to work out how to do what you need to, then get back to them when you know more precisely what you need to do with an estimate for how long.
• The same goes for doing things you have never done before, you will likely deliver sooner if you do some research into how similar problems have been solved by others.
• Break your tasks in to smaller chunks (as small as possible) to estimate more accurately. That way you can say something like "I think A,B and C will take about 6 days altogether but D is soemthing I will have to look". It sounds a lot better than "I have no idea" or "as long as it takes".
• You cannot estimate the time it will to take to find a bug. You maay be able to estimate how long it will take to fix it. A tough bug can easily take 2-3 days to track down and fix. Bugs in code you already delivered will eat into your time on subsequent developments.
• Always let them know when you hit a problem that will make your deadline slip well before your deadline. That way your boss is forewarned when talking to his boss/client.
• If you over estimate and are lucky enough to have some extra time, either test it some more or use the time to develop something else that will be useful to your productivity as a developer.
• If you are continually bullied into agreeing to arbitary deadlines, constantly harrassed or feel your explanations are recieved as though they were outright lies then quietly start looking for another job at a firm that understands software project management before your health inevitably suffers.

Answer 13

Here's a link to a great book by Steve Mcconnell (aka Mr Code Complete): http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=ntt_at_ep_dpt_3 - Software Estimation Demystified

The basic steps are:

• break down the pieces to understandable/workable chunks (look into workbreakdown structures)
• if there's an item that you need more info on, note it and make sure you inform your manager ASAP
• the piece's that you have should include items that are like others you've done before - which should make it easy to provide an est. on those, items you have some 'rough' idea about how long it SHOULD take (add a % over your gut reaction time based on your comfort level - say somewhere between 10% and 30%) and those items you just have to take a wild guess at (add a % range to those, which could be anywhere from 30% to 500%)
• put you list of deliverables together in a spreadsheet, name each item, comfort level of completing (high to low), your time est. - which could be a range (min. 1 day to max 5 days) and any notes that could include questions and assumptions.
• present it to your manager and discuss

A doc to talk to that includes the items needed to be completed, questions, assumptions and a range of possible delivery dates speaks a lot for your level of programming maturity - compared to someone who throws out a # of days/weeks (or just a snide remark) and never comes close. If your manager doesn't appreciate that - find a new manager.

Answer 14

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.

Answer 15

Murphy's Law of Time Management:

To figure out how long something will take, start with how long it should take.

Then, multiply this by 2.

Then, move to the next higher unit of time.

Thus, if a project should take one day, it probably will take two weeks.

Answer 16

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.