2008 / January 2^nd/ Refining your estimation skills

One of the most important traits that separates junior level developers from senior level developers is the ability to accurately estimate projects. Every junior level developer I’ve ever met thinks they know how to accurately estimate a project, but few can estimate with any real accuracy. It’s taken me three years to move from the mindset that I know exactly how long X takes to the mindset that I have no clue how long anything will take. But my accuracy has increased in leaps and bounds.

Estimation is a tricky thing: if the answer were easy to come up with, your client/manager/co-worker probably wouldn’t be asking you. As vague as the answer can be, it’s probably the most important thing you’ll ever do in a project. It determines the budget and timeline you’ll have for the project and ultimately create a baseline for measuring success. As such, it’s vital that you exercise and refine this skill as much as possible.

Keep track of progress

The most fundamental step toward accurate estimations is keeping track of your progress. This is easiest in small compartmentalized activities. Next time you sit down to chop out the HTML/CSS/JS of a project’s master template, time how long it takes you to do it.

The second step is to keep track of your co-worker’s progress. As a projects get bigger, teams get bigger, and soon your estimation skills must include estimations of other developer’s time. Keep track of their progress in multiples of your time.

All hours are not equal

Productivity is a tricky thing, and almost impossible to account for. As developers, we know that sometimes you seem to get dozens of hours worth of work done in a day, while others it feels like you’ve accomplished nothing. Here’s a few oddities I’ve learned:

• The longer the project schedule is, the less productive hours become. A three day long project will be much more efficient than a three month long project.
• If you are implementing other people’s code (third party apps, existing custom framework, etc), productivity will be hampered by at least a factor of two. Writing new, clean code is far more productive (it’s more enjoyable to fix your own mistakes than someone else’s).
• Each junior developer you add to a project reduces the efficiency of the senior developer by at least a factor of two.
• Angry/nasty clients will severely hamper the morale (and thus productivity) of the team. Conversely, happy, thankful clients will increase productivity. Account for the attitude of your client in estimations.

Duration versus hours

One of the smaller lessons I’ve learned is that sometimes the determining factor in an estimation is duration, not hours. Hours can be made up in weekends, longer days, and additional developers. However, some activities will take the same duration of time no matter how many hours your throw at it.

A good example of this is bug fixing. Bug fixing in my experience is most usually a duration-based estimation, not an hours-based estimation. Keep in mind when I say bug fixing, I mean the portion of a project’s time for bug fixing — not necessarily fixing specific bugs (which is an hours-based estimation).

How long will it take?

Ultimately the final answer for your estimation will come down to two different values. Hours/cost and duration. How you communicate that value is almost as important as the estimation process itself. Claiming something will take fourteen days is dramatically different than claiming something will take two weeks. Here’s a nifty little chart stolen from The Pragmatic Programmer.

Duration	Quote estimate in
1-15 days	days
3-8 Weeks	weeks
8-30 weeks	months
30+ weeks	think hard before giving an estimate

Best case, worst case, target

Another highly effective tool in estimation is to really develop three numbers: one for the best case scenario, one for the worst case scenario, and one with the scenario you feel is most likely to be true. This is important because throughout projects, “unknown unknowns” pop up all of the time. Maybe the filesystem in your subversion server just crashed and you have no source control for a week. Maybe the client got a hold put on their budget and development needs to be a paused for a week. You just never know — and the only way to account for these is by guessing. You minimize the risk of that guess by giving different scenarios.

Your estimation is wrong

Alright, so you’ve figured out the baseline parameters, developed a model, and calculated an estimation. You’re just about to hit Send and fire it off to your boss — but there’s one small problem: your estimation is wrong. Always remember that you’re really just guessing. Think about how confident you are with your estimation. Would you bet your next month’s salary that you’ll come in within 20% of project costs?

For smaller operations, this probably isn’t too risky. If you underestimate a 20 hour project by 150%, you’ve only lost a little more than a week. If you underestimate a 5,000 hour project by 150%, you may be sentencing your company to an early grave.

The good news is the same as the bad: your estimation is wrong. Managers, project managers, account executives, and clients all know that estimations are wrong. If you find out that your estimation is way off balance, you can probably remedy it somehow. As long as you accept the fact that you’re wrong early on, finding out you’re wrong isn’t so painful later on down the road.

Now let’s hear what estimation tips you’ve learned!

1. 

   hcabbos

   January 2^nd | #

   Excellent article. Good stuff as always!

2. 

   Noah Everett

   January 2^nd | #

   I couldn’t agree more with your thoughts about working with third party code. When I’m asked to estimate a development project at my work that deals with third party code I always throw on a hefty amount of “hour padding” to allow for the big unknowns you will encounter with someone else’s code. And like you say its just not as fun.

3. 

   Katie

   January 2^nd | #

   When dealing with code other than your own triple the time you think it will take – or if you can’t take a look at the code before giving an estimate make it times 10. This is the worst case scenario – and in most cases when you are brought in to fix something things must be pretty bad.

4. 

   Josh Delsman

   January 4^th | #

   It’s also quite easy to overestimate a project, and come through sooner for a client and make them happy. However, it is much more difficult to tell a client, “Look, I need to bill you about 20 more hours to finish this project.”

   In short, overestimate (or use that worst case figure) more often, and you’ll make your clients a lot happier.

5. 

   Alex N.

   January 6^th | #

   Excellent article. I need some practice. Like you said though, estimates are always wrong.

6. 

   Geof Harries

   January 16^th | #

   I finally got around to reading this article, and let me tell you, it was very much worth the effort. Great points and suggestions, Kyle.

7. 

   Keri Henare

   February 4^th | #

   What about 16 to 20 days duration?

8. 

   Improving Your Process: Blueprinting your Estimations – Monday By Noon

   July 21^st | #

   [...] of the most difficult parts about client work is the estimation process. It’s been written about before, and I’ll continue to write about it. Project estimation is one of those things you should [...]

Name

Email (will not be published)

Website (optional)