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'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.
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.