Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have designed a site using WordPress. This was just a test WordPress site. I am now okay with the coding in PHP, JavaScript, CSS, and WordPress. Now my senior wants me, just by looking at a JPEG image and the requirements provided by the client, to estimate the time required to do a project.

I don't know how much time I should estimate for the project. Can anyone tell me how to handle this intelligently?

share|improve this question

The first thing to do is check to see if you're being asked for an estimate or a commitment. Especially in software development, these words are often misused.

An estimate should be a range with an indication of your confidence in the values. For example, you might estimate a project as 25% confidence of accomplishment in 5 days, 50% in 8 days, 90% in 12 days. If you track your estimates over time, the midpoint of your range should be under your actual time about the same amount it is over.

A commitment is an agreement you will have the project complete in N days.

In my team, we use estimates (ranges) with each other. But product management gets a commitment number, even if they want to call it an estimate.

Once you know whether you're being asked for a real estimate or a number to be used as a commitment, decompose the project as a whole into discrete tasks. You want a list of the work that needs to be done, with each task being no more than 3 days in length. Ideally, half to 1 day's work, although it takes a lot of practice to be able to decompose a project into pieces that size without doing a lot of design up front.

Include tasks for research and prototyping if you don't already know how to do something.

When you're done breaking the project down, add up your total and there's a number.

One of the advantages of breaking down this way is that you'll get early warning if a project starts to go off the rails with tasks running long, and you can then make adjustments accordingly.

share|improve this answer
Key phrase: " takes a lot of practice..." Might as well start now ;-) – eflat Aug 15 '12 at 5:38
Can you please rephrase this sentence : "If you track your estimates over time, the midpoint of your range should be under your actual time about the same amount it is over" .I don't understand it as it is right now ! – Razvan Aug 18 '12 at 16:07
Explanation, not rephrase: an estimate is expected to be wrong by definition. If you are estimating accurately, you should be underestimating the actual time by about the same amount and about as often as you are overestimating the actual time. You need to keep data on every estimate you make and the actual time required so you can tell if you are consistently overestimating or underestimating and adjust how you make estimates appropriately. – Dennis S. Aug 20 '12 at 12:59
This is pretty much the textbook way to do it :) – Muz Mar 23 '15 at 3:48

Estimating time is always tricky. I have about 20 years as a freelancer, and while I'm pretty good about time estimates, I come up completely wrong a couple times a year. I've noticed that I never estimate too MANY hours. When things go horribly wrong, it's always because I estimated too few. That's the first thing to keep in mind.

In your situation, I would start with the site you've already designed as a test. How long did that take you? How similar are the requirements and layout to the test site? Having gone through the exercise of making the test site, you understand how long it took to code, how long it took to set up the layout. If the new site is more complex, increase the number accordingly. If you have no idea how to do the new site, build in some research time as well to figure out new techniques.

Good estimating comes from experience. Without a lot of experience, it's a shot in the dark. Perhaps you can give your superiors a range - between 30-40 hours - instead of a fixed number. If you're able, let your superior know that because this is a new type of development, your guess may not be 100% accurate. Most superiors are understanding about this...especially when they know it's a new environment in which you're working.

share|improve this answer

You will give a far better estimate if you do the following:

Break out the project into tasks. Don't forget that research,communication and meetings, requirements definition, unit testing, deployment, etc. are also tasks.

Determine a min, med, and high figure for each task. Sum them up and you have the low, medium and high estimate for the project.

If your organization will translate this into days to complete without adding on overhead - remember that this is a number of hours based on a maximum of 6 hours a day. You have to allow for leave, unavoidable delay, company meetings and other non-project related work or hours. I spent 10 years doing manpower studies and we always figured available time for direct work based on 75% of the available hours in the week for all professionals. So don't forget to add that total to your final number if he only wants a number without details. Your boss may not want to know you added this on, so you may need to adjust your time estimates to account for it. Only add this on if you know your boss is one of those people who will not account for this non-project time himself in passing the figures up the line(how many death marches has he sent you on?).

Next keep records of what you estimated and how close you came. Once you do this for awhile you will have a feel for whether you tend to estimate high or low and will be better able to improve your estimates later. We tend to look back at our estimates when estimating similar work (especially for large projects).

share|improve this answer

In my case - extremely badly.

Estimating time is one of those things that I can never get quite right - it's staggers me on a regularly basis that a task that I've been putting off for days might only actually take 6 minutes to complete.

One thing I do to try and make sure that things are accurate - is I fairly regularly pick one task out of my todo list that I know I'm not going to complete and spend just five minutes on it - quite often it turns out that those five minutes work gives me a big insight into a) exactly those things that I need to have around me when I start this task, and b) exactly how big a job I'm letting myself in for...

share|improve this answer

Your first estimate will probably be wrong anyway, but that's OK. You learn. The important part is to use the feedback to learn quickly.

You could do a detailed list of everything that will probably need to be done during that project. (All the functions that PHP must do for the user. All the supporting functions that PHP must do for the user functions. All dialogs that require CSS tuning. Installing the product. Reading user requirements and talking with user; that's also a lot of time. Fixing PHP bugs. Fixing JavaScript bugs. Setting up the server. Project-related bureaucracy, such as writing this estimate.) Then make a time estimate for each item in the list, and if you are going to write less than 1 hour for an item, think twice; 30 minutes is the absolute minimum.

Now, the important part is: during the project write the real values next to your estimates. Add the items you forgot, and how much time they needed. When you are finished, keep this report -- it will be very useful for making estimates in the future: you will know how much time what takes, and what are your typical mistakes in estimating.

Sometimes giving the most honest estimate is not the best strategy. (In a perfect world this wouldn't happen, but we don't live in a perfect world.) Most programmers horribly underestimate the time they will need; writing a correct estimate for you may put you in a bad light when compared with their estimates. Or your manager may press you to give shorter time estimates. In such situations, make a honest version for yourself, and then make a redacted official version for your manager. Use the honest version for your personal feedback and learning.

share|improve this answer

Tell your senior that, realistically, an "estimate" based on just looking at a JPEG image and the requirements is not a true and reliable estimate; it's just a wild guess.

The answers given earlier, about breaking the job into sub-tasks, are all prone to missing hidden complexity and tasks that are unknown at the time of the estimate, which is why many people take such an estimate and multiply it by a factor of 4 - to allow for hidden complexity and detail that you just can't see from the high-level.

To get an accurate estimate, you have to have a similar task done earlier that you can use as a reference, or do a spike or prototype that will uncover most of the hidden tasks; doing such a spike should take roughly 20% of the overall project, which in itself is a quandary, because how do you know when you've reached 20% if you don't know the overall time... but leaving that aside, you should say that to provide a reliable estimate, you need to spend x hours investigating it, where you make your best guess at x. Then you spend those hours doing the spike, and form that, you extrapolate the time for the overall project.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.