Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
How to respond when you are asked for an estimate?

What are the estimation methods you use in real world projects and found it to be useful. I know there will be lot of theory available, but more interested in realworld usage of estimation techniques.

From my experince, estimation is the most difficult part I had in my projects. So need some suggestions/realworld experiences to learn from.

share|improve this question

marked as duplicate by Karl Bielefeldt, Jonas, Thomas Owens, DKnight, ChrisF Dec 8 '11 at 23:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4  
Take how long you'll think it'll take, and triple it. That way you'll only be slightly over budget. –  Malfist Dec 7 '11 at 20:59
2  
Entire books have been written about how to estimate software projects. This really isn't a good question, plus there are a number of other, more specific estimation questions here already which would answers pieces of this question. –  Thomas Owens Dec 7 '11 at 22:08

4 Answers 4

Do it with the rest of the team. Discussing it will help get things into perspective and think about potential problems you might not have thought alone.

Never forget that you will never have 8 real hours in a day. Meetings, interruptions, etc.

When in doubt, err towards a bigger estimate. Give yourself buffer.

I have had success with applying three point estimation. You could easily build a spreadsheet in advance to help you there.

Lastly, you will get better over time.

share|improve this answer

Multiply by two.

The reason is this... Your manager walks in on Monday morning and says, "Sundar, how long will it take you to implement feature x?" You know the spec and your abilities well, and you think it will take 16 hours or so combined of researching, thinking, writing, testing, coding, and documenting to do this feature. So you tell your boss "16 hours." Now, what you've forgotten to account for is the daily meetings, the things that pop up and cause you to stop work, the time spent consulting others, and the training scheduled for tomorrow morning. Your boss will see "two days" and expect it to be done at the end of the day Tuesday, even though with all your distractions you've only had maybe 12 hours of actual work time.

Point being, if you estimate 8 actual hours of work, people will want it tomorrow, even if there aren't actually 8 hours of work between now and tomorrow.

share|improve this answer
    
... But how do you come up with that initial estimate of 16? I think that's what the question is about. What you suggest isn't a way to estimate, but rather a way to cover your own rear end after you've done the estimating. –  Bryan Oakley Dec 8 '11 at 0:37

In the real world its an art, not a science. Despite what many people will tell you, building software is not the same as building houses, and things won't work out if you try to use the same estimating techniques.

As a rule we estimate at least two different ways, with at least 2 people. The closer the estimates are, the closer to reality they are likely to be. If they are too far apart, we find out why.

Do not micro estimate - at some point your estimates become just numbers used to create an illusion of accuracy, initially it keeps managers happy, but soon it becomes a stick he will weld over you. In most cases, estimates add limited value to the business. My experience is the job will get done no matter what the estimate is, the amount paid should be based on value added, not cost plus, and no software engineer should be working on a job where cost plus is close to value add. Further, I have never seen a software engineer get "paid" for the time he is estimating the next thing, he is usually expected to slip it in in spare time, usually at the end (busy) stage of a project. Therefore, rather than spend obscene amounts of time estimating, give the manager a few numbers and get on with the work.

We do not use estimates for scheduling, that's one of the biggest and most common mistakes you can make. Estimates are just one of many inputs into the scheduling tool.

Re estimate at key milestones.

Estimates are not quotations.

I live by the rule "I do not negotiate my estimates, I will willingly negotiate my charge out time, quality and feature set". I state it clearly and repeatably when required (It's a bit more politically correct in front of customers.).

Read the works of Steve McConnell (construx.com)

share|improve this answer
    
you pretty much nailed it –  Ryathal Dec 7 '11 at 21:57
  1. Make sure that the specification is broken down in to user stories. Estimate each user story individually.
  2. Give each user story a 1 day, 2 day, or 3 day estimate. If you think a story will take more than three days, break it in to smaller pieces. Even if you think it will take only one hour, say 1 day. No cheating.
  3. Arithmetic!

Ask your QA team how long they will need to QA each story too, of course.

share|improve this answer
    
+1 for breaking it down to 1, 2 or 3 days. Nothing larger. –  DevSolo Dec 7 '11 at 21:29

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