Giving Estimates

Sandesh M Patil

How do you provides estimations for your projects? Recently i have given a task to estimates a whole new project which is some what similar to the existing project. There are lot of new requirements. I am new to this. While giving estimations i worry that the estimation do not go wrong. One of my senior(Who left the company after estimations approved) provided wrong estimates and because of this we have to work for extra in the night shift to meet the deadlines. I need a good advice. :)

Cheers,
SMP

My Recent Article
Task List feature of Visual Studio framework

Nagy Vilmos

Start with a 'wet thumb number': A day per estimated class and/or form, screen or report. From there you can move into more scientific methods of estimation[^] such as COCOMO[^].

Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

BobJanova

Think of similar tasks you've done before, and how long they took. Don't forget to include the time 'wasted' chasing down bugs, fixing documentation, waiting for management approval etc – all of these types of issues will recur and you want to estimate them as well as the actual code/tests. If you don't know exactly what is being asked, think about how long it 'should' take ... and then double it (at least). If you are unclear on some things, you will need to take more time to get clarifications, and there's a much bigger risk that unexpected major problems will appear. Estimates are generally supposed to be 80-90% certainty, so the less sure you are, the higher above the value you think it should be you should pick. Think of a probability distribution with a wider σ – the 90% confidence mark is much higher than the mean. If in doubt, err higher; I've found that it's very easy to underestimate and surprisingly difficult to over-estimate.

OriginalGriff

BobJanova wrote:

surprisingly difficult to over-estimate

Is this because work expands to fit available time? :laugh: Plus VAT, of course.

Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

Marc Clifton

Well, according to the Mythical Man Month, we write 10 lines of code a day. So take your existing project, count the lines of code, divide by 10, and that's the number of man-days. That is, as long as there no women on the team! Marc

My Blog
The Relationship Oriented Programming IDE
Melody's Amazon Herb Site

Lost User

Come up with how long you think it will take, then round up to a nice figure, then double it, then round up again if possible. Then a project manager will half it, then round it down.

Every man can tell how many goats or sheep he possesses, but not how many friends.

Not Active

A dartboard usually works :-D

Failure is not an option; it's the default selection.

Mycroft Holmes

When you have completed your development guess by breaking the project down to the smallest bits you can, estimating the man hours for each small piece you take the total and double it, then double it again. As said the PM/Client will halve it and you will probably over run by 30% or so. Estimating is an art, a dying art.

Never underestimate the power of human stupidity RAH

Marcus_2

SChristmas wrote:

Recently i have given a task to estimates a whole new project

SChristmas wrote:

One of my senior(Who left the company after estimations approved) provided wrong estimates and because of this we have to work for extra in the night shift to meet the deadlines.

Ok, now I'm being stupid but I have to ask: Did he really give the wrong estimate? Did he as you will do give an estimate at the begining of the project? Because that will most likely be way off... Usually in a project there's changes being made to scope and functionality, but the changes is seldom shown in the time estimates for the project. They remain the same... Time estimates should be revised and worked on continuously during the project (revise them at milestones, each iteration, each sprint, etc).

Karl Sanford

Aside from the other good advice already left for you, just remember a few things: 1.) It's an estimate, not an exactimate. Your numbers WILL be wrong. Humans are terrible estimators. 2.) Precision can incorrectly convey accuracy. Like if you estimate 8.51 hours, people will think your estimate is exact (see #1). Stick to nice round numbers. 3.) An estimate should be given in a range. Don't estimate just 8 hours, estimate between 7 and 9 hours (see #1). 4.) Try to break down the process on paper as much as possible before you estimate so that you have a firm grasp of the tasks involved. 5.) As you get more/better information, your estimates should change. Most of these tips I got from reading a book by Steve McConnell on Software Estimation. It's a great read: Book on Amazon[^]

Be The Noise

BillWoodruff

SChristmas wrote:

How do you provides estimations for your projects?

As evasively, and as bloated, as possible. I would start by enumerating the necessity of proof-of-concept prototyping for each new feature or ui/ux idea. Then, I would pose a "pilot project," with a certain budget, to fully implement and evaluate those required prototypes, and consider the costs/benefits with existing code-base. Only when that was completed, and completely paid for, would I progress to a more detailed estimate based on the client's selection of which now-proven innovations were affordable, or cost-effective, or requirements. best, Bill

“Every existing thing is born without reason, prolongs itself out of weakness, and dies by chance.” Jean-Paul Sartre, "Nausea"