How to Accurately Estimate a Web Development Project

As a junior developer, getting promoted was exciting for a lot of reasons. It meant I had proven I could take on responsibility without always leaning on more senior developers to guide and supervise me. But it also meant I was being trusted to answer what was quickly becoming one of my least favorite questions: how much time will it take to do this task?

I wanted to find a method to the madness. There are a lot of variables involved—at first it may seem like we’re talking about code but, in reality, estimating is often about people (and worse, often about ourselves, if we’re estimating something we know we will be personally tasked with). A lot of what you’re estimating is time that will be spent thinking and making decisions, and how can you know how long that will take? You can’t know exactly (that’s why it’s an estimate), but along the way I’ve learned some strategies that help me approach estimates with more confidence.

Break It Down...

First, you need to try and wrap your head around the task at hand. When it comes to large, complex projects, it’s usually totally unrealistic to grasp the amount of effort involved in the entire thing with any kind of accuracy—so don’t try. Within any big, overwhelming task, there are almost always small, conceivable sub-tasks. For example, “How much time will it take to create a blog?” is a really big question. “How much time will it take to create form fields for users to submit blog comments?” is an easier question.

…But Get The Big Picture

Before you can break a whole into smaller parts, though, you have to know what those smaller parts are—or at least, know as much information about them as is available at the current stage of the project. If there is any doubt that you understand what you are estimating, you want to ask questions. Sometimes these can be posed to someone who has ownership over the product and can say, “Yes, we want that.” Sometimes you’re just posing these questions to yourself, so that you can better understand and communicate your own preconceived notions about the product. This allows you to say, “This estimate was developed based on an assumption this is what you want.” It can help to visualize the workflows of the project from the perspective of various users to try and discover any important steps that might’ve been missed thus far (for example, “If someone doesn’t fill out the required fields when submitting a comment on a blog post, they’re going to need to see some sort of error message.”) In some cases, you have no choice but to face “unknowns” in an estimate, in which case you should be careful not to assume that something is simple just because you don’t know the ways in which it might be complex.

Review Past Projects

The most valuable reference to have when doing an estimate is information about how long it took to do the same thing, or something similar, on previous occasions. Beyond that, it helps to visualize how much progress you usually make on tasks of this type within a given span of time. Typically estimates are given in hours, so this leads to imagining how much you can do in an hour. 

It’s important to remember, however, that all hours are not created equal. When you think of an hour of your time, are you thinking about a time when you were on a roll, whipping through one task after another? Or are you thinking about a time you spent a whole hour trying to do something one way, only to realize it wasn’t going to work and needing to backtrack? 

Depending on how optimistic or pessimistic you are in your visualization of your own time, it’s easy to have a skewed idea of your own productivity. Perhaps counterintuitively, it can help to take a step back and look at the bigger picture to check how realistic an estimate is. That thing you estimated would take six hours—can you picture yourself starting it in a morning and finishing it in an afternoon? Is this project the sort of thing you’d usually do in a week, or in a month? 

Be Agile

In Agile projects, there is a concept of assigning points to things in order to estimate how much effort they take relative to each other. Traditionally, not just any arbitrary number of points can be assigned—it must be a number taken from a scale, and that scale typically goes something like this: 0, .5, 1, 2, 3, 5, 8… As the numbers get bigger, there are bigger gaps between the numbers you can choose from. This goes hand-in-hand with the idea that it’s easier to grasp small tasks than big ones: when you do have to estimate a big piece all at once, then you should assume that your estimate is not very accurate and tend to round up.

Come Back to It

Do you ever have a problem where the solution seemed a lot more straightforward after you slept on it, or got advice from someone else? Sometimes estimating can be like this too. When possible, there can be a benefit to stepping away from an estimate for a while and coming back to it with fresh eyes. If you really feel at a loss, it can also help to talk it through with someone else or have them double-check your numbers. 

Estimating does get easier as you gain more experience to draw from, and over time developers collectively develop better habits and workflows when it comes to estimating projects. An estimate, by nature, isn’t perfect, but with the right perspective, providing numbers that give a reasonable representation of the amount of work needed is not an impossible task. 

Want more great content like this? Sign up for our newsletter and get monthly updates in your inbox!