Three Reasons to Estimate

Read Time: 6 Minutes

Estimation! Everyone’s favorite topic. It is not uncommon for me to run into a post on social media talking about what it means to do estimation well, or why estimation is a total waste of time (my feed is really exciting, I promise).

Today, I want to give you three good reasons to estimate work that I don’t see talked about as much.

1. Estimation (done well) creates awareness of how much uncertainty exists

When you get a person or group of people together to estimate work, the range of possible outcomes can give you a picture of how much uncertainty there is regarding the work. If I ask a team to estimate a particular ticket/task/item/story/feature/asset/etc. and I get answers ranging from a couple days to a couple months, it becomes clear that uncertainty (and potentially misalignment) exists around that work.

This is incredibly useful. It means there are unknowns we need to resolve. Sometimes it is as simple as clarifying what is being asked for. Other times, it may involve a lot more. I’ve been asked to estimate how long it takes to “make an FPS” before. The asker didn’t appreciate my answer of something like a week to something like 10 years (90% confidence interval). 

But the question is extremely broad. What type of FPS, how well funded is it, how many people are already engaged with it, how experienced is the leadership in making an FPS, what engine are we using, is it derived from a different product or a sequel or brand new, is it supposed to be a blockbuster hit of the year or a slow build live service F2P title, does “shipped” mean live to players in an open beta or launching the game as a 1.0 release, is this a game jam or an established studio building it? 

Note: there is nothing wrong with the question asked. I was able to provide an answer that captured the uncertainty of the question, and if we worked through all those followup questions my guess is we could tighten the range down a bit. 

Sometimes the question might be specific, but you might still get a range of answers from one or multiple people. If you do, that often means that even with a more specific question there are either different perspectives, solutions, or risks being thought of that could create wildly different outcomes.

Asking people to estimate provides you insight into that uncertainty. It can be highly worthwhile.

Unfortunately, most of the time I’ve seen estimates asked for, people aren’t looking for ranges. They don’t want the uncertainty. Despite asking for an “estimate” they actually want a divine prophecy telling them a precise answer. 

This is doubly bad. First, you don’t get to understand the uncertainty. Second, everyone not involved in the work thinks you’ve got this thing locked down precisely. It sets bad expectations. 

A great reason to ask for estimates is to understand the unknowns related to solving/building whatever the team is trying to do. Don’t undermine it by forcing false precision.

2. Estimation (done well) creates a shared understanding of the work involved

When a multi-disciplinary team comes together to solve a problem, and begins by thinking through and estimating the different bits of the experience or feature they are trying to create, they gain insight into everyone else’s world. 

This can be insanely valuable. Technical work that might seem easy to complete is revealed to be complicated when QA says they have no idea how they’d test and validate it, and the engineers all experience a light bulb going off that they don’t have any idea either. 

A solution that looks like a complicated database likely to take months to build is revealed to be a simple printout that one person looks over once a month for 30 seconds and could probably be knocked out by the end of the day. 

Both of the above are true stories that have happened. 

By taking a cross-disciplinary group and asking them to share their estimates for how difficult it will be, the team will get an understanding of all that is involved (or not involved), and will also realize who is going to be bottlenecking things and who will likely be done in a couple hours. You also can have designers or engineers or tech artists realizing that the best thing they could do to complete the work is help the animator or audio or QA by building them some supporting tech rather than finishing “their part” and moving onto something entirely new.

Estimation (done well) encourages collaboration and can break people out of their insular focus on, “what are the things I need to do” and guide people towards, “what would help US get this done?” 

That shared understanding of the work will pay dividends in all sorts of strange ways. And you don’t need to be spending 10 minutes estimating every piece of work to get this figured out, there are ways groups can estimate together very rapidly to achieve the shared picture of what will be involved.

Big benefit here, another great reason to estimate. There are non-estimation ways you can also figure this stuff out, but estimation is a good option in the toolkit for sharing understanding of work.

3. Estimation (done well or not) can tell you when you are off track and need to make big changes

A common problem in our industry is getting teams to make a bunch of overly precise estimates, siloed by discipline, and turning that into a big ol’ project plan or Gantt chart that will tell everyone what to do for the next 18 months.

The expectation is usually absurd, but even in this very broken and time-wasting case, having the estimates in an awful and unrealistic plan STILL provides some value. Because when you get a month into the timeline, and you’re only about a week into the plan, you realize you’re moving way slower than you expected to move.

You immediately know you probably won’t get everything done. Sure, some people will pop up and say that you’re just getting into it, everything will speed up! I’ll let you in on a little secret: they are wrong. I appreciate their optimism; they aren’t helping. 

Knowing rapidly that you’re behind can tell you that something needs to change. You now know you’re going to overshoot your runway before taking off. That’s very valuable.

Now, that’s in a situation where you did a terrible job estimating. Imagine you took the time to capture uncertainty and share understanding of the work as you estimated. Imagine all the teams did that in a way that didn’t take weeks but instead gave you rough numbers pretty fast.

One month in, you can still do that comparison of what was expected vs what actually happened. If you’re on track, great! Keep watching, because you’re likely to discover more work that needs to be added to the plan, or slow down, or hit a major risk that costs a lot of time, etc. But as long as you’re looking at the rough plan, you can use it as a baseline to understand your existing progress. You can check against it and realize that if you’re moving half as fast as you thought you were, you should only expect to get half the plan done. 

That might change what work is selected. It might adjust priorities or cause teams to realign to make sure the most essential bits get done. It may lead to trimming features or going to cheaper backup plans for things that remain essential, even though the new approach is higher risk.

It allows you to respond.

And once a team or studio gets really good at this, they start to be able to pick that stuff up in the first pass, without needing to wait a month or two to validate that the scope is too high. You might just have teams able to estimate, understand the unknowns, share their uncertainty, and tell you that we need to cut scope or otherwise figure out how to reduce the total effort needed or this won’t be done in time. 

Truth like this can hurt. But if you want to succeed, grounding yourself in reality is way better than pretending you’re on track to a ridiculous plan because you basically blackmailed your whole team into giving you reduced estimates so you could make the project plan fit. I get it, do what you gotta do to hold off the investors and all that jazz. But at least don’t buy that nonsense internally, and certainly don’t sell it to your devs. They know better.

Alright, there you go. Three reasons to estimate.

1. Understand and acknowledge the uncertainty in the work

2. Share understanding of what’s involved in getting it done

3. Inform you of when you’re off track so you can respond

Estimation isn’t always needed. Bad estimation is rarely very useful. If the only choice you have is between bad estimation and no estimation, I’d honestly probably go with no estimation.

But if you put some effort into it, you can probably get to GOOD estimation, probably by working your way through OK estimation. And both of those can be worth the cost in helping you succeed in building better games.

Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].