How do you estimate your development time

Question

Duplicate: http://stackoverflow.com/questions/14279/how-to-estimate-the-length-of-a-programming-task

I'll admit it up front: I'm Boris, I'm a junior programmer and I suck at estimating my develop time. I read a few books and was told by my professors how to plan my projects, but my core question never gets answered:

You never know the domain untill after the project. Even if you can ask all the questions you want and can contact the client as much as you could ever desire (let's pretend) I never know I don't know something untill it's too late. I can't ask questions about the domain untill I know I don't know things, right?

I think that's the main reason my estimations are always way off. That and the never ending urge to make things even better. :P

How do the seniors here handle it. Any real world techniques you use? Am I alone in being so much off? Articles suggestions are nice too, but usually they all tell me the things I know, but not my core question as mentioned above.

Answer 1

Improving my estimating was the reason why I started reading up on the Scrum idea of burndowns, velocity and story point planning. My estimates were terrible.

Basically, you give each piece of functionality a relative size (in story points), where a feature that has a value of 4 is twice as much work as a 2. Which is nice and generic, and will work on any project.

So for example, if you do 10 points of work in a 2 week iteration, you have a velocity of 10. If you have 50 points worth of work, you can expect to be done in 4 more iterations, or 8 weeks. As you progress along in the project, you get a more and more specific idea of how long it will take.

If you use those size values, with time-boxed iterations, your burndowns will give you realistic estimates of when you will be done, on any project you come across.

See these books for more information about how to do the topics I talk about above.

• User Stories Applied
• Agile Estimating and Planning

Answer 2

I've tried a number of scientific planning methods, but the most accurate method so far has been the least scientific... the gut-level "Ugh, that sounds like it'll take 2 months" or "gee, I can do that in a couple days".

Answer 3

See

What can I do to get better at estimating how long projects are going to take?

But you're right, understanding the domain is really the x-factor. This is really not a question about scheduling, but about eliciting requirements.

Answer 4

Of course you will know a lot more about the project/domain/client 4 months later than in the beginning, at the time of the estimation. (The opposite would mean that you don't learn anything, which is not possible isn't it). Unfortunately this is not an excuse to avoid estimating. Basically you need to learn in the problem domain. It's not possible to estimate after 5 minutes, or even hours. You have to know how many screens/usecases/tables/modules will be needed. Estimate each and sum the parts up.

I don't take any estimation seriously which doesn't include a summary of at least 10 distinct items. This additive 'creep' is what the human brain handles poorly. This is why people eat more calories than they think, this is why they spend more money than what they think etc.

One easy technique is to make a WBS, a work breakdown structure. Basically you divide the project to smaller tasks until you reach the granularity you don't want to go under.