As a kid learning how to code, I never thought that I would be asked to predict the future as part of my job. Yet here I am, being asked things like “How long is it going to take to finish this feature?” or “What problems are going to arise while we’re working on it?” and “When can we start working on it?”
We create estimates so that we can give realistic answers to those questions and many more inquiries. But before we can give answers, we have to ask some questions of our own.
In working on complex projects, we’ll go through estimation phases many times over the course of a partnership: kickoffs for new projects, new phases of work, and even small-scale estimates during sprint planning meetings. We’re constantly planning and estimating for all aspects of our projects. As a Technical Director, I’m mostly focused on how long it will take us to complete a feature or piece of code.
With new engagements this takes place during the Discovery phase, but we often cycle back to this process multiple times over the course of a project. Let’s take a glimpse into the process that we use at Sparkbox when creating these estimates.
Defining the Features by Value and Effort
Before we can start any estimate, we need to know what we are going to be building. Sometimes clients come to us with an idea, and sometimes they come wanting a specific outcome. So we ask, “What does this product need to do?” Finding the answer usually requires collaboration between Sparkbox and the client. We want to fully understand what the desired outcome is so that we can best plan for what we need to do. This process can take many forms, but we generally like to work with our clients to come up with these requirements. One tool we use to do this is Miro. This gives us a great platform to do collaborative work.
During these planning sessions, we list out all of the features and organize them based on value and effort. This allows us to talk about where the greatest value is going to be created for the client for each feature, establishes a ranking of features in terms of effort, and aligns the project outlook for both our team and the client team.
If we were talking about building a new photo sharing app, the diagram might look something like this:
Once we’re done with this step, we can start to dig into the individual features.
Estimating the Effort of Each Feature
This next phase requires a deeper understanding of each feature. Here we’ll take the requirements documents that we have, any wireframes or designs (those could be from the client or from our exploratory work), and any conversations about what is expected and start to plan. We might even do a quick decomp of the page design to better understand what we need to do. If there’s any magic, it happens here. It’s a blend of science, experience, and instincts.
We usually start this process by giving features rankings based on effort like “T-Shirt Sizes”—S, M, L, XL, XXL. The goal here is not to put precise numbers on how long we think things will take, but to organize them into groups. This gives us the ability to compare features to each other.
For our new photo sharing app, these rankings might look like this:
| Feature | T-Shirt Sizes |
|---|---|
| Backup Strategy | S |
| Image Uploads | S |
| Favorite Posts | S |
| Block Person | S |
| Create Post | M |
| Password Reset Flow | M |
| Server Infrastructure | M |
| Friend Requests | L |
| Gallery View | L |
| User Accounts | XL |
| User Account Settings | XL |
| AI Algorithm to Find New Friends | XXL |
We’ll pull up estimates for past projects with similar features and compare notes on what might be unique about this case. We’ll talk about how our expectations for this feature may align or diverge from earlier work, how changes might impact the time required, what we learned the first time, and what we might do differently this time.
Next, we’ll start to put time ranges to the t-shirt sizes. We might define a small as 90-150 hours, a medium as 150-250, a large as 250-440, and an extra-large as 440-650. Having hours assigned to sizes allows us to compare past experiences to planned features to confirm what seems realistic. We may tweak some of the numbers or move a feature into another bucket. The goal here is NOT to get the number as small as possible. The goal IS to get the number as accurate as possible.
Discussing the Estimate
This is where the conversation really begins. We’ll take all of our information to the client to discuss. We want this process to be collaborative. If something feels too high or too low we discuss it. Maybe there was a misunderstanding or maybe we can change the scope. Maybe the client wants to take on more of the responsibility for some code that we had budgeted for. Or maybe they have some experience that says working on a particular feature is actually going to take longer than we thought. It’s a bit of a dance to get to a place where everyone feels good about how long we expect the project to take, and how much it’s going to cost.
One of the biggest traps here is lowering the cost just to try to make things fit. This is not a good idea for anybody, because in the end, you’re going to be overworked, over budget, or both. If we’re over the budget, we’ll look to adjust scope and focus on the most important things first. The “nice to haves” can come later if there’s still time and budget, or they can be moved into a second phase of work.
This is a place that can get you into trouble later down the line if you’re not careful. It’s really easy to try to start shaving some of these numbers when the discussion about how much it’s going to cost or how long it’s going to take feels uncomfortable. Be confident in your numbers and admit places where you might not know. Having a conversation later on about not getting something done on time is much more uncomfortable—trust me.
It’s also probably good to point out here that even in the end, we leave each part of the estimate with a range. No matter how good we get at estimating projects and writing software, something always changes. Maybe an unexpected problem or an adjustment to requirements will alter the effort needed to finish something, or maybe things go more smoothly than expected. That’s why these are estimates, not guarantees.
Starting the Work
Once we’re all in agreement on a budget and timeline, we’re in a place to look at the priorities and what makes sense to start on first. We’ll break the features down into smaller pieces that we can represent with cards on our Jira board. We track this time on each of these features not only for billing purposes but also as a reference for the next project we do.
And even with all of this estimating, I can guarantee you that some things are going to end up outside of the estimate. After all, we can’t really tell the future. We can only call on our expertise and experience. Like everything else, the more we do, the more we refine the process, and the better we get.
