3 Ways to Plan and Predict Game Development

Just launched a new course about estimation in game development, so topics like this have been on my mind - by the way, VERY excited it’s live! I’ll talk about it more at the end of the newsletter if you’re interested. But let’s get back to the point of this thing.

We are often asked to plan things in game development. 

Too often, we don’t really think through how to do that well, so we throw some random guesses into a powerpoint, call it a roadmap or milestone plan, send it out, and hope no one ever looks at it seriously.

Because, let’s face it, we’re not the best at planning things in Game Dev. While I know of ONE person that can hit deadline, scope, and budget (I believe solo dev helps), the vast majority of projects end up vastly underestimating the work involved, overestimating how efficient things will become, and generally spend the last quarter of game dev wildly chopping away at scope in the hopes of shipping something before running out of money or investor confidence.

I want to talk through three different ways to create better plans and predictability, and I’ll try to keep this brief. The three are:

• Timeboxing

• Estimating

• Measuring

All three of these can help answer questions and provide guidance to teams as they plan out the future. But we’re too often using the wrong technique at the wrong time. Let’s start with timeboxing, as it is both incredibly useful and also the most misused method for planning.

Timeboxing

Timeboxing is when you look at a feature, experience, piece of content, epic, or whatever and decide how long you will spend on it. Some examples:

“A set of character animations takes 3 weeks to complete.”

“We’ll start working on Feature X halfway through the milestone and finish one week before it ends.”

“We’ll spend 5 days researching the best third party solution and give you an answer on what’s out there or if we think it’s better to build our own.”

Timeboxing is easily understood. It’s useful when you have an unavoidable deadline, or for when you really don’t know how long something will take but want to create a constraint so it doesn’t drag on forever.

Timeboxing also causes many of the problems with bad plans we see in game dev today. Because despite the timeboxes being frequently incorrect, many teams take whole sets of them, shove them together into some sort of master Gantt chart, and pretend that it’s an accurate picture of what’s going to happen.

It’s not.

The team knows that, by the way. They know it won’t come true, but they don’t really know how else to create a plan.

The biggest problem is people are acting as though their timeboxes are reasonable estimates or even measurement-based, when often they are the roughest of guesses from people pressured to provide a particular answer.

It’s no wonder long-range planning goes so awry.

The technique for timeboxing is to basically either declare an end date for something, or decide how much time you will invest into it. This is almost always captured in time.

To differentiate, let’s talk about our next method to create plans and predictability.

Estimating

Estimating takes the same work or value that you were trying to timebox, and instead asks a question: how long do you think this will take?

Now, I know many people think this is what timeboxing is. But estimation done well often creates less precision (exact answers) in order to provide higher accuracy (likelihood of being correct). So when I estimate something well, I’m looking to understand just how confident I am in something coming true by a particular date, rather than what timeboxing often ends up being: the earliest I could hope something might be done.

As a result, estimates are often provided as ranges, or from the perspective of, “I’m 90% confident this will be done by X time.” 

Estimates can still be wrong (and often are), but if you have a group of people who understand estimation, you have a better chance of being a lot more right, and of properly scoping things and making better decisions sooner.

Unfortunately, a lot of people think they are estimating, when they are in fact just loosely timeboxing. 

Estimation should acknowledge the volatility and uncertainty of game development. If it does that well, and if you have people who are learning from past estimates and adjusting their internal models of estimating, you can actually get to a point where people tend to be pretty accurate. 

Estimation is usually a bit more time consuming and thought-intensive than timeboxing. Also, because of either ranges or confidence intervals, estimates rarely fit together as nicely in planning charts. This is because the reality of game dev is mess, and our planning charts are often trying to be too clean.

Let’s move to the third method.

Measuring

So, measuring is in some ways the most reliable method of planning and predicting something, assuming there is some degree of stability in your system. 

Measuring involves looking at what has happened in the past and measuring it. 

If you have a content pipeline that has been running for awhile, how long does it take to make a particular type of asset? Is there any consistency? If so, measure that, and it can help you predict what will happen.

You can measure anything that’s been done. Specific disciplines can measure their own work across different asset types. You can measure how long it took to get specific features done. If it’s work that you’ve done, you can measure it.

The problem is, sometimes no one was keeping track OR you don’t have much historical data. In these environments, 

Another thing that disrupts measurement is a lot of change inside your system, because if things aren’t stable, then past measurements may not be good indicators of future performance.

In my experience though, even with some amount of change, looking at the past to understand what will happen in the future has been the best predictor of what actually occurs. Measurement outperforms even really well done estimation, and absolutely destroys timeboxes.

So Which Should You Use? Let’s Look At An Example.

You might think the right answer is “measuring.” It received the most superlatives, afterall! But actually, you should use all three. In fact, in combination is where these three methods really shine. I’ll try to hit some examples without making this too long.

Imagine you’re just putting together a new project based on a limited budget. You have a rough goal or vision for the work you’ll be tackling, and you want to see if it matches with the resources you’ve got.

You do some discovery to figure out an early and probably wrong guess at what’s involved. The team generally agrees they won’t get everything done, but want a better understanding of what’s involved.

Some timeboxes are created for various phases. These are likely to be wrong, and everyone knows it, but we want to know how off they are. So phases are created and defined, and work is put in them. Now, as time goes by we’ll get an understanding of how fast we’re moving relative to that initial guess that became our first set of timeboxes.

Meanwhile, the teams go through and relatively estimate the various pieces of work to be done against each other. This isn’t yet about creating exact predictability or knowing exactly when each thing will finish. This is about understanding the relative size of things.

With our timebox plan and our relative estimates of the work, we start attacking the highest priority things to create the experience we want to create. 

After a few weeks, we start measuring. We realize the plan is off. We’re moving about 40% as fast as we’d put in the initial plan. That’s good to know. It means we’ll need to trim down a lot to ship something before we run out of budget. But that’s ok, that was always likely to be true, and we’ve figured it out within weeks, rather than pretending our plan is real when it isn’t for months, only to panic in the last quarter of dev (ever been there?). We don’t tell ourselves we’ll catch up, or it will go faster later, because we know that’s not what happens. But we will keep measuring! You never know, maybe things will speed up. Just don’t count on it.

We also have been tracking how many of our relatively-sized things we got done each week. Because we gave them numerical values and held out scale consistent, we’ve been able to create a velocity. (Another simpler way that works almost as well or sometimes even better is just count how many items/issues/tickets get completed, and track the average, but I’ll stick with the relative velocity in this instance.)

With that velocity, we can compare how fast we’ve been moving with the total size of our backlog. We now use our measurement of the past to make an estimate of what we will likely get done. We’re able to make some predictions of how far through our current backlog we’re likely to get.

As time continues to progress, we realize that we’re still discovering work. Because we can measure that, we can make some rough estimates of how much larger our backlog will be than when we started - we can estimate our backlog growth.

It’s a brutal process, but we’re moving towards the end of the project. While massive scope has been cut, we did it far enough in advance that we didn’t waste a ton of time polishing stuff that wasn’t that important or building stuff that wasn’t that valuable.

We’re rolling towards the end. There are very specific things, some of them - like experience-wrecking bugs - need the time they take to get resolved. But other things, like key areas to polish or improve, don’t have as clear a done state. We bring back timeboxing for these things, giving artists, designers, and writers small windows to invest into particular areas of the game. These boxes don’t necessarily mean you have to stop at the end, but they force the question: is it worth it going further on this, or should we move to something else that now has a greater need of attention.

As release gets closer, estimation and planning dev give way to planning the release, and everything becomes about helping the team focus on the most important problems and opportunities we have yet to solve/unlock.

Strengths and Weaknesses

There’s a time for all three ways of planning and predicting. Here’s a little more info of when I might use the three techniques.

Timeboxing:

• Great for when you really have no idea and you want to put an arbitrary box around something to prevent it from becoming the endless “sunk-cost” task that’s totally not worth the effort

• Great for when you have a very specific non-negotiable deadline

• Can be helpful in content pipelines, but you need to be REALLY careful, because it can also cause everything to balloon out

• Great for early rough plans that you expect to be wrong, and you’re just trying to get an understanding of everything that’s on the table and maybe get some ordering figured out. This one is the riskiest because people will misunderstand it as a confident assertion of the future and now you’ve set a terrible expectation.

I’ve found timeboxing is great at the very beginning of projects to prevent rabbit holes, and at the very end of projects to prevent overinvestment when critical things need to be done. Timeboxes should be considered strict, but that doesn’t mean you can’t make a judgment call to create a new timebox once the old one ends. The thing you should avoid when timeboxing is constantly extending your timeboxes to match reality while not adjusting future timeboxes. If the timeboxes weren’t the right size, that usually means you need to adjust the whole plan, not just the one task.

Estimation:

• Great for when you don’t have anything to measure yet, and you don’t mind spending some time trying to create ranges or rough likelihoods of completion. Too often this deteriorates into bad timeboxing that sets poor expectations, so be cautious.

• Good when you have been measuring, and are trying to figure out what the future holds by projecting those measurements into the future. Vulnerable to instability in the system, but still can be a great idea.

• Good for rough “sizing” of things to help make prioritization calls

• Good for relative comparison of things that you intend to measure in order to understand just how fast you are likely to go through the backlog

Estimation is a mainstay throughout the length of your project, but especially in preprod and production. You are constantly projecting estimates forward based on what you’ve measured, and creating ranges of likely end dates even before you’ve measured anything. The big thing you need to do to make estimation value is reflect on whether things have been estimated well in the past. Too often teams that are objectively awful at estimation continue to rationalize and trust their current estimates rather than recognizing they created bad ones. This means the bad estimates will continue.

Measuring:

• Should be doing this constantly for just about everything, while keeping it lightweight

• Can be as simple as measuring throughput, or as complex as something like cycle or lead time

• Often you measure what actually happened against whatever timeboxes or estimates you created. The measurement gives you a basis for adjusting future timeboxes or estimates.

• Great for validation. If you have 3 weeks to get something done, and you’re about a third of the way through your tickets one week in, that’s a good sign. If you’re about a twentieth of the way through, that’s good to know because you probably aren’t getting it all done.

Measurement creates the historical data you can use to sanity check what you’re expecting the future to look like. You can’t really measure much at the start of the project because you haven’t started, and even the total amount of work is likely to change dramatically, but as you start rolling forward tracking how much is getting done (by count or velocity), how much gets added, rate of bug discovery, cash outflow, and etc. all become useful for decision-making around what the future holds.

Measurement must be paired with some type of forward-looking estimate or adjusted timebox to really be meaningful. On its own, it just looks backward. It has the best data, but because the past can’t guarantee the future, be aware that no matter how good your measurement data is, it can’t make things hit the deadline. So measure a lot of different stuff that will help you predict the future, but be wary of overinvesting and measuring things that provide low value.

Wrapping Up

So, there you have it. Three ways you create planning and predictability in teams. Timeboxing, estimating, and measuring. Used in conjunction and in the right context they can allow projects to go from unknown anxiety-inducing messes to data-informed predictions. Better, used and approached correctly, they prevent the false narrative that so many studios grasp onto to reduce their anxiety: the idea that the plan we came up with will guide us all the way till ship. 

It won’t. That’s ok. 

Don’t just tape a bunch of timeboxes together into a plan and think that’ll get your game out the door. Teach people to estimate. Measure what’s actually happening. Feed what you learn back into your plan.

If you do this well, you’ll be making hard tradeoffs and tough decisions early when there’s still some wiggle room, rather than procrastinating those things till it’s too late and there’s not much to be done.

New Course Launch

As I mentioned earlier, I’m thrilled to be releasing my early access of Advanced Estimation For Game And Software Development into the wild.

Estimation was the most requested topic when I did some polls last year. I’ve finally got something that’s ready for you, as my early testing group had a lot of positive things to say.

This is a course that aims to make estimation add more value. It moves away from the performative, rote estimation that everyone sees as a waste. It moves away from overly simplistic “project planning” or “poker planning” approaches that are often all anyone is taught.

I talk about who should estimate, why we estimate, why people struggle with estimation and how they can get better, and also spend the most time going into specific techniques for estimation like ideal time, relative estimation, cycle time, and even discuss when you shouldn’t be estimating at all.

If you’ve ever dealt with vague estimates, endlessly moving targets, or wasted time estimating and planning, I think this course will get you more value in less time from estimation.

Inside, you’ll get:

• Techniques and approaches for estimating in real-world game/software teams
  

• Templates, examples, and postmortems from actual production stories
  

• 15+ hours of material (with more coming)
  

• Lifetime access. No subscriptions, no renewals.
  

• Early Access pricing: $497 (full price: $987)

Early access means that I’m not done yet. More modules are still to come, and that will raise the price. But if you sign up now you’ll get all future content for free whenever it releases. 

If you’re looking to get more value out of the time you and your team spend estimating, check out the course HERE

Whenever you’re ready, here are 2 ways we can help you…

—>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].