How to estimate tasks?

[Lasse Koskela]

Originally posted by t ray in another thread in the OO forum:
Hi All,
I am not sure if this is the right place to aks this question but since we are talking about a development process, i am gonna ask this question here. and the question is that how would you estimate a completion time for a given task by a boss? If a boss or manager assigns you a particular task or a module and asks you for a rough completion time for that particular task. what is the real world way to give him/her the estimate? are there any formula or some approaches?
thanks.

[Lasse Koskela]

If a boss or manager assigns you a particular task or a module and asks you for a rough completion time for that particular task. what is the real world way to give him/her the estimate? are there any formula or some approaches?

There are two main categories of approaches to estimating tasks. One is to use a quasi-scientific numerical method like Function Point Analysis, and the other is to use your own judgement. FPA proponents have managed to produce quite good results, I believe, but the vast majority of contemporary thought leaders seem to be in favor of just estimating. If you don't go for a numeric approach, then how you come up with a task estimate has to do with how complex/difficult you estimate the task to be and how much of your calendar time goes to "overhead" like meetings, interruptions, etc.

[Stan James]

We do the "planning game" from XP and other agile methods: List features of the system on index cards and estimate them in some arbitrary units by relative size. We call them story points. All we promise is that an 8-point story is twice as big as a 4-point story. We strongly resist calling them man-days or any duration. Then as we start running the project we observe how many story points we do every week or two. There is a guess at the beginning for how many points per week we'll do, but careful observation as the project gets rolling may change the estimate. The good news for us is that we've been together doing the same kind of project for years and we can guess points-per-week pretty well.

If I had to do a new project with a new team, new domain, new technology I couldn't guess that number. I'd try to hire an FP expert I know for a week or two to get a total project size & duration. Then I'd do my story points and spread them out across the duration estimate. Then I'd observe every week and see if we come anywhere close to that.

[Tim West]

If you're estimating for one-person tasks that you personally will be doing, you could consider following something like the Personal Software Process to refine your estimating.

Essentially, you estimate as Lasse mentions, and record all estimates and times-taken and regularly determine how accurate you are, and any trends (eg, always estimating 20-50% too low).

I've used it before and got utterly bored of keeping paper logs. I looked into Open Source projects that supported it but never really came to anything that I used longterm.

Anyway, the main point I should make is that professional estimating is a skill, and so can be learned - PSP is one tool to aid you. There are similar paradigms for teams.


--Tim

PS yup I know PSP implies a whole lot more than just estimation...see Watts Humphreys =)

[Madison Moose]

We use something called Work Break Down structure, which lists all possible tasks related to software development (right from requirement analysis to implementation). We then break the given tasks in to the ones listed in the WBS and then try to give our best estimate on how much time each task will take.

[Peter den Haan]

One important thing to appreciate about estimates is that they will be wrong, and almost certainly between 25% and 1000%(!) too low. It has already been hinted at in some of the replies above: the only way to get an acceptable accuracy in the estimation process is to feed past experiences into future estimates.

When I do an estimate, I know from past experience I'll be about 100% too low. Is that bad? Not at all. Provided that I understand the problem, the estimate I'm giving isn't "wrong", it's just that like many other engineers I naturally estimate in "ideal development time" where everything goes more or less according to plan and no-one interrupts me. I could change the way I estimate, but then I would probably still be significantly out - but if I simply correct my estimate based on measurements of past performance, I become much more accurate than I could be all by myself.

Similarly, you might have measured that my colleague at the next desk typically needs only 60% over and beyond my estimate. You might also have gather some statistics on how in your environment effort scales with team size. That way, you can accurately determine the impact of team composition and size, and get away from the mickey mouse model of resource allocation (aka "Microsoft Project") where a hundred developers can do a project in a day if a single developer is estimated to take a hundred days.

Since every project is different, you would monitor and adjust these corrections on a regular basis during the course of a project. Agile people call this "project velocity", expressed as the number of estimation hours finished per day.

- Peter

[Dmitry Melnik]

Q. to experienced estimators: Do you guys bid for fixed bid contracts? How do you estimate your price before you started working?

[Junilu Lacar]

Originally posted by Peter den Haan:
One important thing to appreciate about estimates is that they will be wrong...When I do an estimate, I know from past experience I'll be about 100% too low.

I remember seeing a tagline recently that went something like:

X's Law: Your estimate will be 100% too low, even when you take X's Law into account.

[Lasse Koskela]

Originally posted by Dmitry Melnik:
Q. to experienced estimators: Do you guys bid for fixed bid contracts? How do you estimate your price before you started working?

I wouldn't call myself an "experienced estimator", but I'm pretty sure that the general methods for estimating (guess based on past experience and the perceived complexity of the project, or calculate a number using some formula optimized based on historical data) apply to bidding as well.

[Peter den Haan]

Originally posted by Dmitry Melnik:
Q. to experienced estimators: Do you guys bid for fixed bid contracts? How do you estimate your price before you started working?

Get an idea of the scope: user interface (screens or whatever), processes, complexity of code and data, interfacing, performance and quality requirements. Compare these figures with those of the projects you have done in the past and extrapolate. We do lots of fixed price work and are regularly refining our estimation process, trying to roll past experience back into it. Not that I'd claim that we are always particularly successful at it...

- Peter
[ August 05, 2004: Message edited by: Peter den Haan ]

[Mark Herschberg]

Peopleware has some good data on estimation. My upcoming book goes into estimation best practices in chapter 4.

First, as others noted, no matter what anyone else wants, record your own honest estimatations, and then record actual time. You can discover trends in your estimating ability.

Second, get input from others. They might spot different issues you may not.

Third, remember that 1 day != 8 hours. It's important to understand what overhead you have (lunch, meetings, email, etc). Related to that, consider how much uniterrupted time you have in a day.

Forth, consider in the estimation (this may be part of your estimate or covred elsewhere): design, development, testing/fixing, documentation, and most importantly integration with the rest of the system.


--Mark

[Don Stadler]

An interesting method for quick and dirty estimates was in a book named Debugging Java published a few years ago.

It consists of estimating the raw number of hours the subtasks in the piece of work would take if you knew everything perfectly. Then, for each subtask, rate yourself from 1 to 8. 1 = could do it with your eyse closed, 2 = have done it, need to look things up, 3 = haven't done it but have a good notion (like an example), 4 = have a colleague who has done it, all the way to 7 = probably can't be done but you can't prove it.

Then multiply the subtask by the exponent of the difficulty level; i.e. 1 = 1, 2 = 2, 3 = 4, 4 = 8, 5 = 16, 6 = 32, 7 = 64. So if you have a 4 hour task at level 4, 4 * 8 = 32.

I've used it, and while it's not sophisticated it does a better job than most of my rushed estimates and I can give a rough estimate in a couple of hours this way.