Few tips on estimating production time

A few tips about time estimates

Final boss fight – 4 weeks. Additional co-op mode – hmmm… 3 months. Main menu music theme – several days? The ability to convert features into a realistic time estimates hit the top three on the national list of the most difficult tasks that a game producer has to cover. Yep, I made that up, but the problem with estimating is real and it concerns not only producers but also other game makers who, at a certain point, need to think about how much time it will take to add another fantastic feature into their beloved app. Let me give you a few hints here. 

Basics #101

The most common/ground-level/kindergarten/basic mistake that you can make is to deliberate on such estimates on your own. It gets worse (really nasty!) if you are trying to estimate time for something not being within your field of expertise and what is to be done by someone that you don’t know. VERY bad things happen if you do it in such circumstances (too long to talk about it here). Instead, try talking with the person made responsible and an expert in the field. Try to come up with an estimate together. Please think about how deadlines are set in your company. Are they all consulted with at least a group of experts or are they imposed on everybody?

Collaborative estimates are an essential thing here. So I’ll just assume that you do that. Ok? You still there, right?

Step two

I’m not the most experienced producer but I do this for a couple of years now. The most common, first answer that I get for the question “how long (…)?” is “I don’t know.” Sure, more experienced people say it less often but still. Don’t be discouraged by such an answer. Not only it is (as I mentioned) difficult to estimate and the task length depends on number of facets but also we simply don’t like to have deadlines hanging over us. So it’s natural that we stray from imposing them on ourselves.

Let’s go further and assume that you worked this out with your peer so that he gave you an estimate. He claims that he’ll make requested 3D model of a unit (let’s say it’s a Si-Fi, rocket-launching, armored vehicle for a strategy game) in two weeks. What do you do? You run to your boss and tell him the good news that your team will meet the deadline because it will take just two weeks to finish the unit, right? Wrong.

Think about it as a process

Here comes the second tip about estimating production time – people interpret things in regards to their own business. Bit too general? Ok. If you ask a guy about his model he will tell you about the model (artists are just an example here, it actually concerns all people in the gamedev, also producers and their reports). It doesn’t mean that this game’s unit is finished! You still have to animate it, provide it with some particle and sound effects and an UI icon. Hell! You will have to come up with a name for it and figuring this out can take weeks if you take into account bouncing back and forth from you, design team and a publisher. This leaves our poor (producer) guy with bad news for his boss or his wife/girlfriend (not leaving work early today…). Getting back to the point. It may seem trivial when you read it but there are actually two strong psychological effects involved in the process that may mislead your estimates. First being a personal perception. If you ask an artist, “How long will it take to FINISH a unit?”? He will say, “About 1-3 weeks.” If you ask a producer the same question, he should respond, “About 1-2 months.” Both of them are right. They just MEAN different things! Artist was thinking about a model (his responsibility) while a producer has to take into account all the tasks starting from the design, concept art and also testing, balancing and debugging because his job is to coordinate the process.

What’s up with those three lines in the title?

Second effect, that I want to mention, is the strong (and unconscious) positive attitude towards information that confirm our theory or are favorable to our goal. You may call it “wishful thinking”. Consider the following situation. You are a business guy and you really want a certain deal to be closed fast but it requires implementing three lines of additional code to an old game. So (basics #101) you ask the programmer, “How big of a deal it is”? “I’m not sure but it shouldn’t take more than an hour or two,” coder replies. Again, our business guy hears what he wants to hear! That it’s nothing and it will be done in a flash. In reality this process turns out to be much longer. This programmer would need to dig up an old code branch, debug it (old builds tend to crash if you were constantly improving your engine), add those three lines, check if they did not interfere with anything else, redirect the build for testing and send it for certification, not to mention update description that needs to be localized. Note that the last part can take about few weeks (on Mac App Store, for instance). Ultimately, the final build is being published a month after the initial request was made although implementing those three lines took just several minutes! Of course it doesn’t have to be that bad, e.g. some ways of distributing games do not require any certification but the funny thing is that at the same time this situation could also be much worse. For example, this process could stretch out for another month due to the certification rejection. So be warned and keep in mind the following phrases while estimating feature time frames.
Chart below presents this situation and clearly shows how wrong someone could be by underestimating the length of the process that can be started by a simple request of adding just three lines of code. 

 

Lessons to remember

That leeds us to a summary of the most important hints about estimating production time in a game development studio: