2 ms·
Still, some projects will take longer than others, and it's possible to distinguish a 2-week project from a 2-quarter project, even if they actually end up taki
by bonniemuffin 11y ago
Still, some projects will take longer than others, and it's possible to distinguish a 2-week project from a 2-quarter project, even if they actually end up taking 3 weeks and 3 quarters.
I feel like comparative sizing is the most important part of software estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this project, we can't do these other 2 smaller projects". This is still a valuable exercise, even if all of the estimates are each individually quite inaccurate.
- HeyLaughingBoy 11y agoI agree completely. It's the only way I've found that works. Start the estimate by saying "these rolled-up, roughly estimated tasks come to about a year in total." Now we know it's closer to a year than to two months. Once we start, we can continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't see. We can give you X functionality in a year, or all of it if you can wait 18 months" Lather, rinse, repeat. With experience and good time tracking of tasks, you learn how long things take: "every database we set up in the last year took about 10 days to get right." Now you know your estimate to configure a database and get it online is 10 days, not the optimistic "I can do it in an afternoon" that everyone claims. The key to good estimating is good historical data. Problem is devs hate tracking their time and reporting accurately.