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?"
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.
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.,
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
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.
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.