Slashdot Mirror
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?"
Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it. The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate. Once you start doing that, then you can adjust your estimates to allow for more features or yes.
This is my sig.
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.
For me it really depends on how accurately they spec it out. If it is a general idea I can be an order of magnitude off easily. If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate.
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.
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
I'm god, but it's a bit of a drag really...
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.,
Show me a staff that consistently delivers products on time and one of the following will always be true:
1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)
2) Project times are consistently overestimated.
It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.
I just ask my manager how long he's already told the client it's going to take.
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.
Please do not read this sig. Thank you.
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.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
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.
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.
I make the initial best-guess estimates based on past projects and past developer performance. I track the initial estimate, and then I track all effort spent as it is logged. I.e. each checkin gets an "effort spent" number. I then track "actual vs. estimate" and come up with a total amount of overrun so far. I take that overrun, get a percentage (e.g. "over by 15%") and then add that back to the total estimate.
So, if the total estimate is 100 man hours, and we are currently over by 15%, I then say it will actually take us 115 hours total to finish the project.
This is based on the sage wisdom of Mythical Man Month: if you first estimate is off, so are all your estimates, usually by the same amount. As depressing as that might initially sound, it's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.
So I mark my first estimates as "estimates" and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate. It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating :-) The norm on the projects I was a developer on was that overrun was closer to 90-100%. My last project I managed was 25% with new developers--I considered that a victory :-)
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Precise guess.
Accurate estimate.
In just one word: oxymoron.
I almost always bill per hour. Most of the time my clients give me an email or verbal idea of what they want over the phone. I try to get as many questions answered as I can without wasting time.
I then take the task and break it down into as many bite-sized subtasks as I can. This does a couple things:
1. It shows where I have unanswered questions
2. It's easier to estimate "add 3 new roles to management interface" and "add cart admin role to admin interface" than it is to estimate "make admin area more secure".
Once that's complete (for this round), I put all those line items into a spreadsheet. I then estimate the number of hours it takes in a reasonable best, and worst, case scenario. So "add cart admin rold to admin interface" might be 3-4.5 hours.
I then add all those up, and add about 33% for planning, and 33% for testing/deployment. Sometimes it can be more or less depending on my experience with the client. I then give that spreadsheet to the client and say, I'm pretty confident your price will be within this range. The areas that have high variability are the areas we need to work on nailing down further. I will bill you actual time taken, but I'll let you know if the range is nearing the top number so we can re-evaluate. That almost never happens, or I should say that when it does, it's almost always because the client has asked for more work, and they understand this.
Customers almost always appreciate this approach and find it helpful. Most of the time I only do this for the first project for a client, and then they just ask me to give them a verbal idea of how hard the project will be since they trust me.
For the very occasional fixed bid work I do, I just take the high number, pad it a bit, and double my hourly rate. I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance. I usually don't spend a lot of time on fixed bid work because, frankly, I usually don't want it.
www.clarke.ca
Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.
I am the richest astronaut ever to win the superbowl.
And probably more importantly than estimating accurately, we aim to estimate consistently. Then we compare actual rate of feature completion against the estimated size of remaining features. We've landed within a single sprint of estimates over a year long release with 20+ developers.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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).
Sadly, even that doesn't work.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Our development time is estimated based on when management has promised a feature/enhancement. Even when management has forgotten to tell the development team the promised date, until a few days beforehand. Apparently this is a very accurate way to estimate programming/testing time, because somehow we always make the dates. Of course there are times when sleep is not accounted for in these estimates.
I like this methodology.
We break the project into use cases.
Estimate each use case.
Identify the risk of each use case (High = New stuff that may not work or is hard to predict, Low = Straight forward coding to implement).
Divide the work into time blocks (3 to 5 weeks, I liked 1 month increments).
Each month, measure actual progress against plan.
Another thing I do for my resources is to maintain an ongoing metric of whether they over or underestimate and apply it to their estimates. So eager girl who says she can do it it 50 hours but took 75, gets a +50% to her ongoing average. Meanwhile, cautious lad who estimates 80 and took 60, gets a -25% put in with his average.
I usually have a meeting with the stakeholders AND the developers to firmly establish scope and when scope changes, we renegotiate the deadline.
By putting the high risk items early (just do a proof of concept that Xserve 3.85 really does work under Unix 3.71 over a VPN connection before you commit 180 million dollars of dead end work to the project).
While I do not normally overwork my resources, if one of them bids 30 days from now to deliver, then if they have to work extra to make that date, then so be it.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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!
Probable impossibilities are to be preferred to improbable possibilities.
Aristotele
Stack overflow detected...
my $quality = 100;
my $initial_project_time = length($piece_of_string) / ($count_programmers);
my $real_project_time = ($initial_project_time + ($scope_creep_time * $count_non_it_business_staff)) * $3.14;
if ($slave_driving_boss eq "yes") {
$real_project_time = $real_project_time / 2.5;
$quality = 60;
$bugs = random;
}
I am not a software guy, but an analog microwave design guy. All too often management expectations can in no way jive with reality. Instead it is often necessary to intentionally underestimate times, and later find specific items to pin the "delays" on. Along the way so much money and resources get involved, that effectively you've gotten the project through the second trimester without management realizing they are pregnant. Beatings ensue, but at that point those of us with scarce skills can't be laid off, so we shield our faces and live on to design another day.
Yay, another successful project out the door despite management...
It is to laugh. Developers are never given enough information about what it is they are supposed to deliver. You want a fast sort algorithm? I can do that in, say, less than a week. You want an award winning social networking web site that brings in millions of hits? Might take me, hmmm, a month or two? Maybe more. Oh, please remember to factor in testing and documentation time, people.
Join the window installer's union, where prosperity is a brick throw away!