Written by Peg Bogema, President of Stout Systems
Let’s start with this statement: You cannot accurately estimate anything you haven’t done before.
If I asked you to estimate how long it would take you to make a new suit for jolly old Saint Nick or to walk to the North Pole to take his measurements, you would probably laugh at me.
But in many, if not most, cases, that’s what people in technology are asked to do. We have to figure out how long something will take that we’ve never done before.
Here are two definitions of estimate from yourdictionary.com: (1) an opinion or a guess of the size, worth or cost of something, (2) a rough calculation or guess.
Notice that both definitions include the word guess.
Guessing how long a project is going to take isn’t going to be very popular with your customers or stakeholders.
Other than gaining the insight and wisdom of twenty or thirty years of experience, are there things you can do to improve your estimates? Yes.
(1) Break tasks down.
When we teach estimation to software developers, we quote Joel Spolsky, founder of Trello, co-founder of Stack Overflow (among many other illustrious accomplishments) from his Joel on Software blog.
Pick very fine grained tasks. This is the most important part to making your schedule work. Your tasks should be measured in hours, not days. (When I see a schedule measured in days, or even weeks, I know it’s not real)…
If you are sloppy, and pick big “chunky” tasks (“implement grammar correction”), then you haven’t really thought about what you are going to do. And when you haven’t thought about what you’re going to do, you just can’t know how long it will take.
As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you’re not breaking it down enough.
If there is any one thing I hope you’ll remember, this is it. In order to estimate and schedule correctly, you need to break your project down into very small tasks—so small that they aren’t longer than 16 hours in duration.
If you think your way through your project at this level of detail, you can then roll up the task estimates into a reasonable guess about the scope of a project.
Anything done with less detail isn’t an estimate. It’s a WAG. (If you don’t know this acronym, look it up. You’ll get a chuckle.)
(2) Track your actual hours.
Once you’ve created your task breakdown, don’t just put it in a drawer in your desk.
The way you improve your estimation skills is by tracking your actual hours.
You said Task X would take 4 hours. Were you right? If not, were you over? Under?
Tracking actual hours provides a feedback loop so that you can learn from your mistakes.
This isn’t about beating yourself up over your crummy estimating skills. It’s about observing how you did and using your observations to hone your estimation engine.
Were you generally overly optimistic? If so, by what factor? You can try multiplying your estimates by your optimism factor to see if that brings you closer to accurate.
Were you only off on a specific type of task?
Did you completely forget some tasks? When we work with software developers, they’ll often omit time for testing or bug fixing or status reporting or meetings. If you observe that you forgot to budget time for a specific task or two, you can add that to your estimating template so you don’t make that mistake again.
Your estimation skills will grow by leaps and bounds if you track actuals and then retrospect about where you were off and what you can do to improve.
(3) Don’t confuse task estimates with a schedule.
If you estimate a project at 80 hours, that doesn’t mean that the schedule is two weeks.
You have dependencies on others. You need to schedule a meeting with someone or get feedback from a busy executive or a thousand other things that will slow you down calendar-wise.
Where task estimation is something you tune on a personal level, scheduling is something you tune on a client or team or company level. As you become familiar with the various stakeholders you’ll be working with, you’ll know whether or not scheduling meetings is easy or turnaround times are quick.
You create a schedule to accommodate all of the delays and pauses that you anticipate.
And then you pad the schedule to allow for disruptions. And then the next time you do a project with the same group, you have a good sense of how things will go.
Summary: As a newbie, you shouldn’t expect that your estimation and scheduling skills will be good. That’s no excuse to continue to suck at it for very long. Follow these tips to improve your skills. This area is one of the major differentiators between someone who is viewed as junior versus someone who is viewed as senior. It will pay off in raises and promotions. So do it!
This is a technical/business article catered to developers, hiring/project managers, and other technical staff looking to improve their skills. Sign up to receive our articles in your email inbox.
If you're looking for a job in the tech industry, visit our job board to see if you qualify for some of our positions. If you're looking to hire technical talent for your company, please contact us.
Stout Systems is the software consulting and staffing company Fueled by the Most Powerful Technology Available: Human Intelligence®. We were founded in 1993 and are based in Ann Arbor, Michigan. We have clients across the U.S. in domains including engineering, scientific, manufacturing, education, marketing, entertainment, small business and robotics. We provide expert level software, Web and embedded systems development consulting and staffing services along with direct-hire technical recruiting and placements.
Top comments (0)