Refining your estimation skills

Posted: June 1, 2008 in SDLC

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 file-system 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.

By: Kyle Neath

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s