- Posted by Ian Suttle on September 7, 2007
- Filed under General | Process
Surely you've received this question from a business stakeholder: "When will my project be completed?" What you'd like to say is "I'm not sure, but I'm working on it" which of course doesn't fly. Software estimations are notoriously difficult to accurately predict. Book after book has been written to explain how to develop an accurate time estimate for software development. Most books are wrought with theories, complex mathematical formulas, and a lot more resource requirements than you've got at your disposal.
Personally, I don't find this a realistic approach in such a dynamic environment as the web. Most engineers I've seen revert to a review of the requirements and simply tag each section with a quick estimate. "Okay, that's an easy form and will take me three hours. This function will be about two days..." In the end you have a tally of wild estimates. Odds are you're going to be held to your timeline so go ahead and tell your life "be back later." If you can look at a single requirement and know it's going to take more than a few hours, you don't have enough details on the task or you haven't broken it down far enough.
So what approach is realistic? Let's start with project scope. Do your homework. Understand what you're building. Often you'll have
to know what you're starting with as well. If that's the case and
you're modifying an existing application be well versed in refactoring
patterns. If you determine the project will require more than a couple of weeks break it in to phases if feasible (see Sprint used in Scrum). The idea is it's far more realistic to accomplish shorter term goals (days, weeks) than longer terms goals (months, years). Think about it. Would you feel more confident in completing a single module or a group of modules within a single timeline? Also keep in mind, change happens. Requirements change, technologies change, resources change, and priorities change; all items likely to be out of your control. By taking on a short term goal you reduce the chances of change affecting your goal and efforts.
Once you've etched out a short term goal, it's time to design your solution. I don't mean create a web site diagram and a flow chart. I mean that and more. Design your database schemas including tables, stored procedures, functions, and relationships. Design your class libraries including methods, enums, types. Design your pages including controls, third party libraries, UI. You're designing how these elements all work together, but remember, just for your short term goal. If you can't design your solution at this level of detail, you don't know what you're building and need to go back to step one - do your homework. However, realize the inverse. You can probably predict with good accuracy how long a stored procedure will take to write. Not only can you estimate a stored procedure but you can estimate a method, class, user control, table, etc. Don't allow any less than an hour or any more than four hours per task. If more than four hours you need to break the task out into more detail. As you generate your estimates document them and track your progress. Don't forget to account for code reviews and project documentation. TFS work items are great, but Excel worksheets can do the trick.
I also recommend having the design and estimations reviewed by a senior engineer with a proven track record of achieving their timelines. This is your check and balance. If you estimate a stored procedure will require one hour of development but it really requires two, you were 100% off. Apply this boo boo to multiple estimates and your two week project can quickly turn in to a three week project. That's a 50% increase in time. Expect you'll have at least some items underestimated. Your reviewer should be able to help you adjust and pad your estimates to account for these inaccuracies. In the end, you'll have a good estimate to work from.
Let me also say I'm a realist. I know engineers cringe at the thought of documentation. However, my money says engineers dislike providing estimates they aren't confident in and missing their deadlines more than their disdain for documentation. When you can provide accurate estimates you gain a lot: confidence, trust, more normal business hours, and a rockstar rep.
