Estimating, like anything in software development, is a skill. And it's HARD.

No one starts their coding career good at estimating. After years of experience, most of us end up merely mediocre at it.

But that doesn't mean we shouldn't try to get better because informed estimates are incredibly valuable.

I hope that after reading this post, you'll feel more comfortable estimating.

But before we dive in, why would you listen to me after I just said most devs are mediocre (at best) at this skill?

During my 10 years of consulting, I’ve had to estimate and sell most of my projects as well as track my time in 15-minute increments for billing. As a result, I’ve become really good at forming accurate estimates.

But how?

Whether we're estimating in story points or in-person time, how do we find "the number" to assign a task?

How do you make a cute fall outfit? Layers!

How do you make a cake even yummier? Layers!

Why is Shrek so lovable? Layers!

I find that thinking about the code you need to write in layers is super helpful when creating an estimate.

There are many ways to break down a project or feature into layers.

Data > Application > Presentation

My preferred layering strategy is Data > Application > Presentation.

Most of my projects are small enough in scope (3-6 months) that I don't usually need to think in finer detail than that.

The data layer is your models and database.

The application layer is the business logic that occurs in controllers and service classes.

And presentation layer refers to the UI stuff, both styling and user interactions.

View > Controller > Model

If that layering concept doesn’t feel right for you, you could also think in MVC (model, view, controller).

The view is the stuff in the frontend (and sometimes what’s returned by your API if you have one).

The controller is exactly what it sounds like.

And the model is the application models and data models.

Backend > Frontend

If we're doing even smaller estimates like sprint or task estimates, that 3-tiered approach might be too heavy-handed.

Thinking in backend and frontend layers may be enough.

Data > Persistence > Business > Service > Presentation

And when we're working with a big, complex system, we might have to go even deeper.

Adding a few layers between our presentation and data layer separates concerns even further.

I rarely have projects that need this level of thinking. But projects that exceed 12 months might be good candidates. Hopefully, you don't have to estimate too many of these 😬

Example

As a user, I want to "favorite" an image

Let’s take a look at how we might break down an estimate for the above user story that my team worked on.

We had already built a UI that displayed images in a gallery. The stakeholder wanted users to be able to click on an icon overlaid on each image to add to or remove from a “Favorites” list.

We can break down this story into the following smaller tasks (remember, layers!):

Data

• Create a FavoriteImages table
• Add ability to create a FavoriteImage for the current user and provided image id
• Add ability to delete the FavoriteImage for the current user and provided image id

Application

• Create an API action that accepts the image id
• Toggle the “favorite”
• Return the favorite status to the frontend

Presentation

• Add an overlaid icon
• On click, send the image id to the API
• On success, update the icon based on favorite status
• We’ll need 2 icons
• Read favorite status on page load to render the icon correctly

When estimating in person time, we can estimate the hours each one of these smaller tasks would need. Then add them up to get the initial estimate.

When estimating effort, listing out all the smaller tasks is still valuable. It helps make sure we're not oversimplifying the story or forgetting any necessary work.

An estimate will never be perfect. But it's a useful tool for setting expectations. And it provides a framework for us to know when to course-correct.

Estimating is a skill that you can build just like any other.