How Do You Accurately Estimate Programming Time? 483
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?"
Chop features. (Score:3, Interesting)
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 what I usually do. (Score:5, Interesting)
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.
Uhh, Scrum is not an estimation method (Score:5, Interesting)
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:Simply, no software required. (Score:4, Interesting)
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).
Bill per hour (Score:3, Interesting)
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.
we use scrum/invest stories (Score:3, Interesting)
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.
Re:W.A.G. (Score:3, Interesting)
In all seriousness, a friend of mine who's been in the business for a while goes with a refinement of W.A.G.:
1. Get a WAG from the developer.
2. Apply this formula: Real estimate = WAG * (actual time for previous features / WAG for previous features)
3. Tell the developer that his original WAG is what we're using, so he actually hits something pretty close to the real estimate.
As a result, management has a pretty good (although not completely perfect) idea of how long something is going to take, based on developer's WAGs.
We agile the crap out of it... (Score:1, Interesting)
Re:My Ass (Score:1, Interesting)
I've taken this a step further and convinced my boss that the numbers I pull out of my ass don't mean anything. They continue to ask for them but understand that it's possible for me to be WAY out in either direction.
Re:The formula (Score:3, Interesting)
Sadly, even that doesn't work [wikipedia.org].
Re:Chop features. (Score:3, Interesting)
Nice insight in handling the ship date opportunity.
My method was to carefully calculate (as well as possible) the ship date points of the various features/modules and when:
Writing mainly in a C environment then double the time estimate which is pretty accurate and the client is usually very pleased to see things fall in line ahead of the estimated dates
When writing in other languages (RoR, etc.) then it is tripled and the customers are still pleased.
And these clients and customers are where you get your referrals.
Rational Unified Process (RUP) (Score:3, Interesting)
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.
Good Estimates Lead to Layoffs (Score:3, Interesting)
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...
Re:Simply, no software required. (Score:3, Interesting)
I hope that doesn't get a funny mod. It deserves better.
Re:Method changes based on scope (Score:3, Interesting)
Estimating programming time is often estimating how long it will take to do something that has never been done before.
And if it has been done before, it's out the door to India already, which I'm sure someone else will also point out.
It seems to me that a lot of project estimation is done to serve a hidden purpose.
Yes, and the hidden agendas are formal inputs to the schedule estimation problem. Been there, done that. One of the major terms in the non-linear politics is who gets the blame when a product shipped with working functionality proves impossible to extend in the next coding iteration because the wrong foundation was chosen. Do you want the estimate consistent with my professionalism, or with grenades baked in for the next guy to work on this? How many accountants say "the audit will take six weeks, but I could have it done in three if I cut a few corners"? The engineers are often the easiest departed to prey upon to extract the necessary lies to feed management fiction in the face of disgruntled investors. Our work process is among the least subjective, but our quality standards are among the most subjective. Works or doesn't work is hard science. Maintainable or not maintainable is pure sociology (under most boardroom conditions).
Some day I would love to seal my estimate into a cryptographic vault on the basis that my estimate is only correct if I don't tell anyone. As soon as you tell someone, that person immediately goes around changing the assumed conditions.
I'd also love to try a pair programming exercise where the project manager sits down beside me while I work and then I go into a stream of conscious mode:
Well, without knowing more about this tool, my estimate is one to eight weeks". If we spend anywhere from two to eight hours, my estimate will likely improve to an interval of (t,2*t) + investigation overhead. Which path would you like me to take?
Generally I can lucidly explain every decision point, usually three or four levels deep off the top of my head. Every time my companion antiparticle shies away from taking the abrupt path to clarity, the estimation error expression spouts more terms, in some cases combinatorially depending on sub-problem interrelationships.
With a certain level of development maturity, the shortest distance between two points is to drive clarity at every step of the process coupled with an intense feedback-loop concerning local discoveries. It wouldn't be a mathematical contradiction is the decision strategy with the lowest expected time has a particularly ragged expected variance. In fact, I believe this is true.
Another thing to throw at my companion antiparticle is that you can't just take the statistical average of the anticipated decision chain. If the variance of a distribution is poorly behaved (e.g. real life, according to Nassim Taleb) higher order moments of your distribution are undefined. Put that in your pipe and compute the average.
Of course, there are exceptions to the recalcitrance of black swans, such as when your business is in a lucrative application domain with slow moving market conditions with only gentlemen competitors if any competitors at all, and your company is funded by private money who politely and happily declare "looks like we're still on target to reach profitability in year ten, good work chaps".
You want an estimate? Pony up an accurate spec. (Score:2, Interesting)