Time Estimation for Front-End Engineers

While working on iOS at several companies in the Bay Area, one of the most effective and transferable skills I’ve learned is how to accurately estimate my projects.

It’s easy to estimate the minimum amount of time it will take to build a feature, but it’s much harder to estimate when that feature will actually launch after delays, code reviews, and other processes. The latter is a much more important metric for yourself and your team.

Why estimate?

When you first hear about a project, the last thing you want to do is guess how much time it will take. You may argue that you’ll finish it sooner if you don’t spend the overhead estimating, but unless you work for yourself (and don’t have any external dependencies or deadlines), the benefits of time estimation are worth the time spent on it.

You will be able to better prioritize and plan your projects, and people who depend on you will have a reliable time frame in which to expect your completed work.

Initial time estimation

I like to follow a linear process of estimating, using both top down estimation for an initial ballpark figure, and bottom up estimation to confirm the validity of the broad estimate.

Top down estimation

When you estimate top down, you think of the project as a whole. This involves thinking of previous projects and past experience, along with your gut, to make a general estimate.

If someone thinks of a new feature during a meeting and asks you, impromptu, how long something will take, you’re going to be engaged in top down estimation. It’s good to make this initial estimate, but since you have no details on it, it’s generally inaccurate.

That’s why, once you’ve made this estimate, it’s good to delve into a little more details.

Bottom up estimation

This kind of estimation involves breaking down the project into the smallest possible pieces, and estimating each piece individually. For example, if you’re supposed to add autocomplete to a search field, maybe you want to think of the following chunks:

• Adding autocomplete network API request – 1 day
• Adding UI popup to display autocomplete results – 1 day
• Integrating network results into the view – 1 day

Sometimes this step involves spending some time making prototypes or researching some libraries that can be utilized.

Once you get this estimate, compare it to your top down estimate and work out any inconsistencies, if any. It’s likely your bottom up estimate is more accurate, but thinking about this can help you make better quick top down estimates in the future.

Buffer time estimation

Once you’ve gotten some more detailed time estimation, it’s time to make sure you add some buffer. How likely are you to get blocked on each item?

One thing to note when you’re estimating your days is that you may not spend the entire day coding. There are code reviews, meetings, interviews, breaks, emergency bug fixes, and whole host of things that can come your way each day. If you have an 8 hour day, maybe it’s best to estimate around 4-6 hours of coding each day, depending on your usual overhead and other obligations.

After I estimate, I normally add about a 30% buffer to my projects. If I initially think it will take 10 days, I’ll add another 3 days to make it 13.

If I’m in a new codebase or using a language I’m not familiar with, I’ll add a buffer of much more, sometimes even doubling an estimate since I’ll be spending lots of my time getting up to speed.

Communicate updates

As the project goes on, it’s likely that unexpected thing will still come up and invalidate your initial time estimates. If you added some buffer beforehand, you should be fine, but it’s smart to still go back and make sure things are still on schedule. If your buffer wasn’t large enough, it’s better to communicate that earlier than the day before it’s supposed to be finished.

Review your completed projects

One of the best things you can do to improve your time estimation skills is to reflect on each project that you complete. Look at when you started, when you finished, all the roadblocks along the way, and see how accurately you estimated those during the project. You may see patterns emerge that you can take into account and explicitly mention to your team next time you are estimating.