How Do You Accurately Estimate Programming Time?

itwbennett writes "It can take a fairly stable team of programmers as long as six months to get to a point where they're estimating programming time fairly close to actuals, says Suvro Upadhyaya, a Senior Software Engineer at Oracle. Accurately estimating programming time is a process of defining limitations, he says. The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization. Upadhyaya uses Scrum to estimate programming time. How do you do it?"

Comments

Simply, no software required.

[loftwyr]

I take the amount of time I think it will take, double it and move it up a time unit.

So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.

Re:Simply, no software required.

[WrongMonkey]

In other words: the Scotty Principle.

Re:Simply, no software required.

[Rob the Bold]

I take the amount of time I think it will take, double it and move it up a time unit.

So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.

Exactly my method too. I assume we both stole it from the same place, but I can't remember where. I am also ashamed that it is often right.

Which either means I'm lousy at estimating or brilliant. Or maybe just lousy at implementation. Or maybe nothing at all.

But it doesn't matter, of course, since the boss will ask "Are you sure?" And we all know that that means "try to come up with an estimate that fits my predetermined schedule." So you either cut features/quality by plan or by fact. Usually by fact, since no one wants to give up anything. So you give up whatever doesn't happen to be done (or give up your release date -- which is also a feature of a sort).

Deadlines are useful, though, in avoiding a DNF type situation.

Re:Simply, no software required.

[Chapter80]

The method I was taught in school, back in the days when Arthur Andersen existed, and prior to Andersen Consulting or AssVenture (or whatever they're called now), the method that was taught to me was credited to them, and looked like this:

Estimate how long it will take, if everything goes right. Call it T1.
Estimate the expected time it will take, knowing how some things usually go wrong. Call it T2.
Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99% sure you can get it done within this amount of time. Call it T3.

The Weighted average estimate is (T1+(4*T2) + T3)/6

This yields some very odd T values, but often works out to be a reasonable estimate. The developers may tell me "If all goes well, it'll take 2 days. I expect it to be 4 days. But worst case, it might be 40 days." And you end up with a 9.6 day estimate. (which is SIGNIFICANTLY different than the "I expect it to be 4 days".)

----

The part I learned from working for a major computer manufacturer was this:

Take whatever estimate the developers tells you, and tell the client to expect it in double that time (from today). If the lab tells you they'll have a fix by tomorrow, tell the client it'll be there the next day. If the lab tells you it'll be ready in three months, tell the customer 6 months. That way, as time goes by, the estimates become more real, and the variation from the estimate becomes more refined. And it accounts for the unavoidable time between when the lab releases the work, and when it gets installed at the customer's site.

If, in January, I was told by the developers that it'd be ready in 2 months, I will tell the customer to expect it in 4 months (May). If in February, I haven't gotten a revised time-frame, then we still expect it in four months (June).

Manage expectations, and don't let the customer down (particularly when things are outside my control).

Re:Simply, no software required.

[computational super]

Hofstadter's law: It always takes longer than you expect, even after accounting for Hofstadter's law.

Re:Simply, no software required.

[jellomizer]

We do it backwards. The boss gives us the timeframe and we make the specs to match it.

Re:Simply, no software required.

[DeadCatX2]

I multiply all time estimates by pi, to account for running around in circles.

This is what I usually do.

[tool462]

I'll throw together a script that takes in all of the project parameters as input, then based on the number of people in the team, past performance, scheduling deadlines and intermediate deliverables, comes up with an estimate for final delivery.

Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.

Re:This is what I usually do.

[tool462]

I figure it boosts my efficiency by getting all my wasted time in up front.

My Ass

[i_ate_god]

I pull numbers out of my ass.

If I am ahead of schedule, rock on
If I am directly on schedule, rock on
If I am behind schedule, creatively blame something that is out of my control to begin with, rock on

W.A.G.

[ipb]

After 40+ years of programming it's still a Wild Assed Guess.

You're never given enough time to prepare your estimate, marketing has already
determined the delivery date, and management doesn't know what it is you're
supposed to create anyway.,

It's Easy

[BabyDuckHat]

I just ask my manager how long he's already told the client it's going to take.

Re:It's Easy

[VoxMagis]

I wish I had mod points for this - it's the most realistic answer yet!

Well, I *used* to use the entrails of goats...

[gestalt_n_pepper]

But the folks who used the table in the lunchroom complained, so we now use the far more sophisticated system of tea leaf reading. This upsets nobody but the tea drinkers as we frequently need to user their cups before they're done, but then tea drinkers are wussies anyway.

Quid pro quo

[HangingChad]

The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.

My time estimates will be as accurate as your specs. You stick to the specs, I'll stick to the estimate.

Method changes based on scope

[Anonymous Coward]

Are we estimating a tweak to an existing feature? Or the creation of an architecture for a high-volume real time production system?

That matters. Methods that are cost-effective for one are worthless for the other.

And there are other concerns...like....how much are we allowed to spend on the estimate itself? That will put limits on the accuracy and precision (the difference between which is critical to understand in any methodology), as well as further determine what kind of estimation methodology can be used.

In order to answer the question put forth in the summary, I will first need more relevant details.

My experience working both with huge and tiny projects has taught me this:

One size does not fit all.

Uhh, Scrum is not an estimation method

[pclminion]

Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.

This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.

Re:Uhh, Scrum is not an estimation method

[JohnFluxx]

In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them. There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc. You can't "create and agree" on performance, debugging etc backlogs ahead of time.

Re:Chop features.

[Hognoxious]

features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.

Have you ever asked which feature has the highest priority, and received the answer, "all of them"?

The type of twits who give that answer always think they're combining the wit of Oscar Wilde, the insight of Confucius and the cock of John Holmes.

A better formula

[CorporateSuit]

Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.

Re:Chop features.

[2short]

Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features.
I've never seen a team that could estimate, months in advance, when a particular feature set would ship.
I've been part of great teams that regularly review progress and have the power to adjust priorities.

Software Estimation: Demystifying the Black Art

[strimpster]

I would recommend reading "Software Estimation: Demystifying the Black Art" [http://www.stevemcconnell.com/est.htm]. When estimates are created, there are many tasks besides "programming" that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning. We have to admit from the beginning that it is an estimate and is hinged with certain unknowns. If the unknowns are cleared up, we can be more accurate with our quoting (this is why requirements gathering should be done with careful attention). Also, since the estimates are just that, they need to not just be a number, but more of a range (if you have to give a number, choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90% certainty - and give the confidence with the estimate). One thing that I have learned is that I never negotiate on estimates/price, I only negotiate on functionality. If a manager/client wants it quicker/cheaper/less hours, fine, but I'm not going to change the number unless the functionality changes or more unknowns are cleared up (helping me to quote more accurately).

Re:Function Point Analysis and Man Hours

[boaworm]

I always learned it like this:

1) Make a guess, very generous one. Make sure there's plenty of space.
2) Double it, as you will need an equal amount of time for testing and bugfixing when you're done writing.
3) Double it again, as Murphy will make sure everything will fail, which will lead to inevitable delays.
4) Multiple by PI

Now you're pretty close to a realistic estimate!

Re:Chop features.

[tempest69]

Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features. I've never seen a team that could estimate, months in advance, when a particular feature set would ship. I've been part of great teams that regularly review progress and have the power to adjust priorities.

Shipdate was the feature dropped in Duke Nukem Forever.. So it ships with all features..