3 ms·

Could you share more details on how you used historic estimates? You basically described me. I've never found historic estimates useful in practice, of course I

• wazoox 10y ago
  That's quite simple, really. If you've carefully tracked your past projects, by comparing tasks from the planned project to those you've done of similar complexity you can make more realistic estimations. It works best on a long-running project. When you plan a new feature, you can gauge really accurately at what speed your current team developed a feature of comparable complexity, so as you go forward you get better and better estimates. Joel Spolsky explained it there: http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html
• HeyLaughingBoy 10y ago
  I know, for example, that under a certain annoying development process coughPSPcough, I will produce code at a rate of 30 LOC/hour when measured from initial requirements gathering through handing code off to testers. I know this because every line of code I've written (using that company's process) for years has been measured and timed. So now the estimation process becomes a matter of figuring out how many LOC (as a proxy for effort) a given feature/project will be and then dividing that number by 30. It is scarily accurate, but like I said, it's been aggregated over thousands of lines of code for years.