The Scotty Principle: Handling Time Estimates During Game Development
Any die-hard Trekkies out there should be familiar with the Scotty Principle, even if you haven’t heard it referred to as that. You may not, however, know how it can apply to game development.
Read on and you can find out. But first, for the uninitiated…
What is the Scotty Principle?
The Scotty Principle (also known as The Scotty Effect or The Scotty Factor) is the technique of adding extra time to your estimates when asked how long a task will take so that you appear to be a wizard when you accomplish the task quicker than you first claimed.
It’s named after Montgomery “Scotty” Scott, the Chief engineer aboard the original USS Enterprise in Star Trek The Original Series, as played by James Doohan. Scotty had a habit of claiming an issue would take longer to fix than the time available but somehow managing anyway.
This tendency to over-exaggerate his estimates was addressed directly in the following conversation from the movie Star Trek III: The Search for Spock:
Kirk : How much refit time before we can take her out again?
Scotty : Eight weeks, sir. But ye don’t have eight weeks, so I’ll do it for ye in two.
Kirk : Mr. Scott. Have you always multiplied your repair estimates by a factor of four?
Scotty : Certainly, sir. How else can I keep my reputation as a miracle worker?
Kirk : [over the intercom] Your reputation is secure, Scotty.
The core of the Scotty Principle is to underpromise and overdeliver. It has since been used as shorthand in a variety of different contexts. This article is about how it applies to game development.
Why is it Important to Game Development?
Simply put, because people are terrible at estimating time. In fact, we’re so bad at it, that there is a real non-Star Trek related name for it; The Planning Fallacy.
The Planning Fallacy is defined as the tendency to “underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.”
We do this by applying an optimistic bias and disregarding evidence of how long similar actions took in the past.
So, what does this have to do with game development? Well, game development is a highly collaborative process with lots of moving parts, dependencies, and budgetary constraints. The upshot being, time estimates matter, a lot.
Overly optimistic time estimates can lead to a game being delayed, it’s developers having to crunch, the game coming out buggy, or even being canceled altogether.
This is compounded by the fact that production and management have a tendency to ‘squash’ or ‘trim’ estimates. You’ll know how this feels if you’ve ever told your manager that something will take 5 weeks and they tell you to get it done in 4.
This behaviour happens for a variety of reasons. The two most common are
- Because they assume (either consciously or subconsciously) that you are already applying the Scotty principle (even if they don’t think of it by that name) and you have given them an inflated estimate.
- Because they are trying to motivate you and they think that applying pressure is ‘good management’.
One common (but more specific) reason that management does this is that they may not actually be familiar enough with the technology being used to make a good estimate. People in management positions were often trained decades ago and their day-to-day work no longer involves coding or the use of applicable software. Our co-founder Martin remembers a time when the CEO of a company he was working at decided to get his hands dirty. He sat down with Martin’s team to personally lay out how something they had been struggling with should be developed. He wrote them a long design document, then called a meeting to explain how they would need to implement the solution. After the CEO walked away, Martin asked his co-worker, “Am I right in thinking that would work on a very small scale but would be a super impractical memory hog if applied to this problem?” The developer just nodded his head looking like he had been slapped.
The worst part of squashed estimates is that it can happen multiple times as you go up a reporting hierarchy, leading to a cascade of condensed estimates.
Whatever the reason, the result is the same. Tight deadlines.
The judicious application of the Scotty Principle can be a way to combat the negative repercussions of the Planning Fallacy and squashed estimates.
Right about now, you might be thinking “Why not do everything you can to make your estimates as accurate as possible, instead?” To stick with the Star Trek metaphor, I like to call this the Geordi Principle.
The Geordie Principle
The Geordie Principle is named after Geordi La Forge, the Chief Engineer of the USS Enterprise-D in Star Trek: The Next Generation. It’s most aptly demonstrated in this conversation between Scotty and Geordi in the episode Relics:
LaForge : I told the captain I would have this diagnostic done in an hour.
Scotty : And how long will it really take you?
LaForge : An hour!
Scotty : Oh, you didn’t tell him how long it would really take, did you?
LaForge : Of course I did.
Scotty : Oh, laddie, you have a lot to learn if you want people to think of you as a miracle worker.
For the purposes of this article, I will define the Geordie Principle as always giving the most accurate estimates possible using the information you have available at the time.
So, it seems pretty intuitive that this would always be the best way to go, right? Honestly, in a perfect world, it absolutely would be. But, as previously established, we are terrible at doing this. Most engineers, designers, and artists (even those with years of experience) have a tendency to think of a solution for a problem facing them, assume they can implement that solution relatively quickly, then when they sit down to do the thing they realize they just underestimated by a lot. The prevalence of Crunch in the games industry and the number of games that get caught in development hell are a testament to this.
All the fancy production techniques that have been developed to combat our inherent weakness for planning accurately could (and do) fill books. But this article is about one tool that you can add to your toolbox. In order to fully explore why this tool can be so handy, we have to touch on one more aspect of game development.
That is factors outside of your control. To stretch the Star Trek metaphor to its breaking point, I’ll call this the Q Dilemma
The Q Dilemma
For anyone who hasn’t seen Star Trek but has somehow made it this far, Q is an all-powerful god-like alien (Star Trek is full of them), first appearing in the pilot episode of Star Trek: The Next Generation. Q has a fixation with Captain Jean-Luc Picard and a habit of suddenly appearing on federation starships at inconvenient times.
I consider the Q Dilemma to be anything that has an effect (usually negative) on development that’s outside of your control or difficult to anticipate. And, for bonus points, the Q Dilemma often happens at the worst possible time and leaves you feeling powerless.
Examples of the Q Dilemma in action are:
Publisher Interference
Most game studios are reliant on publishers to keep money flowing so that everyone can get paid. This can be a problem when a publisher turns around part way through development and decides that they don’t like the direction the game is going in. If funding gets pulled, or if publishers start making demands on how a game should be made. This can wreak havoc on production.
A powerful entity coming in and dictating how you live your life. This is the prototypical Q Dilemma.
Technology Upheavals
Second to publishers, game developers are also beholden to a slew of tech giants that enable games to be played or distributed. Sony, Nintendo, and Microsoft for consoles, as well as Apple and Google for phones, are the ones that most consumers are aware of but the list goes on with Nvidia, AMD, Epic, Unity, and more all having a direct impact on how games are made and consumed.
Every time a new console is announced or the terms of service change for the App Store, developers have to scramble to figure out what changes they need to make to stay competitive. And that’s not even mentioning when support for a major product is discontinued. If you’re not lucky enough to be one of the privileged few who find out in advance, you can easily find that months or years of work has to be flushed.
Unexpected Market Reaction
Picture this, you’ve been working hard on your game for years, it’s finally shaping up. There are still problems with it but you’re confident you can get them ironed out before launch. You’re in the home stretch which means you need to start showing your game to the public. You spend a few weeks polishing up the start of the game and you use it to record a gameplay trailer.
You’re not sure you’re happy with it, but you’re always more critical of your own work than other people so it’s probably not as bad as you think, right? You release the trailer and… everything goes horribly wrong, the public hates it, you had no idea but this isn’t what they wanted at all.
This is more or less what happened to the developers at 343 Industries when they released the first gameplay trailer for Halo Infinite. The market was expecting amazing next-gen graphics worthy of a launch title on the new generation of consoles. Instead, people complained it looked like a game that could have been released years ago. The backlash was strong enough that it was one of the reasons mentioned when the game ended up getting delayed. In this case, the customers were Q
Misleading Marketing
This one should be ‘in your control’ but there are situations where it isn’t and it happens so often that it’s worth including. Letting your marketing get out of control is never a good idea. Companies are particularly vulnerable to this when they let their publishers or exclusive platform partners do marketing for them. If a feature is promised during marketing the expectation and hype that is created by that can be extremely damaging. Sometimes the damage can be managed with a quick tweet or a well-worded press release but often it can spiral out of control and lead to developers struggling to deliver features they never even planned to include.
Should You Use the Scotty Principle?
All of the issues and dilemmas mentioned above can be mitigated and, in some cases, ignored completely if you apply the Scotty Principle in the correct way.
First, let’s illustrate how things can work if you do or don’t apply the Scotty Principle.
If you underestimate how long a major task will take early in development, the only way to rectify it is to do one or more of the following:
- Take time away from other tasks (trim features or allow more bugs)
- Eliminate other tasks entirely (cut features).
- Delay your release.
- Spend more resources (usually money).
- Overwork your employees (Crunch).
If however, you overestimate how long a major task will take (the Scotty Principle) then once that task has been accomplished, you may have a surplus of time, meaning you are able to do one or more of the following:
- Accomplish “stretch” goals.
- Give more care to tasks (increase polish and eliminate bugs)
- Release early (probably not).
- Save money.
Of the two options presented, the second is preferable in almost every case.
The argument against this is Parkinson’s Law the adage that “work expands so as to fill the time available for its completion.” Taken another way “If you give people extra time, they’ll waste it.”
Fighting Parkinson’s Law
To be frank, that is a risk, using the Scotty Principle may lead to a dip in productivity in some cases. At the end of the day, you have to decide if that risk is worth taking when weighed against the risk of putting your team through undue stress and possibly losing your game in the process.
That being said, this is where some of those fancy production techniques we mentioned earlier come into play. There are plenty of easy to implement tweaks that can be made to stop your team from losing productivity when employing the Scotty Principle, many of which are already present in existing software development systems like Agile.
Cut Your Tasks Into Smaller Chunks
A core part of many productivity methods, cutting your tasks into the smallest increments possible means that even if your estimates are over (or under) inflated on a single task, the effect on the overall project is limited, minimizing the risk or using the Scotty Principle. It also helps because once a single task is completed, there is another, clearly defined, task that can be tackled next.
Reward Your Team When They Are Ahead of Schedule
The core tension between managers who squash estimates and their employees is a lack of trust. They believe that if they give an employee two weeks to do a task which only takes one., the employee will spend the second week relaxing and doing nothing at all. This assumption is almost certainly inaccurate. Most people are more productive when they feel like they are trusted and have a sense of ownership over their work. But if you believe this is a problem that is likely to occur on your team, remember it can be mitigated by rewarding employees when they are ahead of schedule.
It doesn’t have to be lucrative, even something as simple as a long weekend or a fancy takeout delivery on a Friday can be enough to keep people’s morale up.
Prioritize Carefully
Divide your features into ‘must-haves’ and ‘nice-to-haves’ and focus hard on a small number of the most important tasks. Apply the Scotty Principle to your must-haves and assume your nice-to-haves won’t be included unless you finish your must-haves early. The satisfaction of picking a favorite feature off the cutting room floor can be a hell of a motivator to work ahead of schedule.
Our Suggestions for Applying the Scotty Principle
What I’m about to say next may go against every instinct you have, but if you’ve come this far please don’t abandon us now. Our team has several managers with long histories of delivering on time and to budget, and we strongly advocate building the Scotty Principle into your culture. “Scotty-ing” your project doesn’t mean multiplying your estimates by 4, that would be unrealistic. For most teams it looks something like this:
- Encourage your team to multiply time estimates by a factor of 1.3 to 1.5, and keep doing this up the chain.
If an engineer thinks it will be a one day task, the producer should assume 1.5 days minimum and leadership should be happy to report to any partners that they should have that issue on lock within two days.
- Always round estimates up to the largest significant number.
If you have one task that is 30 minutes, one task that is 4 hours, and one task that is 4 days. The estimated time for all those tasks should be 1 week. Buying yourself that extra wiggle room will pay off.
- Track agility and make sure you account for meetings and other issues.
Be really accurate about tracking team agility. Adopt a point-based or time-based system. There is a tendency to believe that more experienced people have greater agility. Makes sense, they have the chops to work more efficiently so they get more done, right? Wrong, your most senior members (Leads, Creative Directors, Senior Whatevers) of your team have the least agility on average. Even if they can accomplish a task in half the time of an entry-level team member you still need to assume they will get the same or less than that team member done on a weekly basis. They have constant demands on their time. Not only do they have to attend most meetings, and do a bunch of administrative tasks, people are just constantly interrupting them with questions and requests. That need to switch focus regularly may make them good at jumping from one task to the next, but it will also make them less efficient overall.
If you follow the above guidelines, when a Q Dilemma strikes you should have enough flexibility to deal with it well.
I hope you managed to get some value from the article above. If you did, and if you managed to apply the Scotty Principle, let us know in the comments below or directly.
