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.
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!
Want to receive career and technical articles and/or job announcements straight to your inbox? Subscribe to our mailing list! As always, if you are looking for new opportunities in the tech industry, feel free to browse our IT job openings or contact us.
COVID UPDATE: We are now hosting free career webinars every week. Visit our calendar of events.
Peg Bogema is the President of Stout Systems. She was John Stout’s first hire after he formed the company in April 1997. Peg has expertise in project management, software development management and technology recruiting. She has a Bachelor of Music degree from the University of Michigan and is a Certified Scrum Master. Peg is raising two very active boys and a ridiculous number of orchids.