Uncertainty in Schedules

One of the problems with long term schedules is that they try to plan away uncertainty. Uncertainty can take many forms, but generally falls into three categories:

1. Uncertainty in what you are building.
   The exact specifications of what makes a fun, hit game are impossible to document and schedule. "Finding the fun" includes many iterations and experimentation.
2. Uncertainty in technology.
   Game developers face a rapidly changing technology base with products that require major innovation. Many games have been delayed or cancelled because the predictions of what the new technology could achieve or how long it would take to be implemented were usually optimistic or uncertain.
3. Uncertainty with the developers.
   Given the same design document and schedule, two different teams will have entirely different results and levels of success. People aren't cogs in a machine. Teams gel differently and talent is highly variable.

Agile methodologies were created for use in cycles of product development that have a high level of uncertainty. Uncertainty increases the further out you try to predict the future, or the larger the task you are trying to estimate (see Figure 1).

The benefit of agile is in iterating on short-term, detailed estimates of short tasks. Agile limits the detail of planning to the matching of certainty and priority. When we have a lot of uncertainty in high priority features, we break them down into smaller parts that fit into an iteration. This way we can continually refine the estimates for the whole to be increasingly accurate.

_{Figure 1}

As mentioned earlier, game projects are often divided into pre-production and production. If you want certainty in production schedules you need to address the three areas of uncertainty during pre-production. This has to be the goal of pre-production and the measure of when pre-production is complete. Ideally pre-production will demonstrate a certain percentage of all asset types combined in a shippable demo version of the game that demonstrates the final fun factor, performance and resources required to build the remainder of the game.

Iterative Pre-Production Followed by Detailed Production Schedules

Some Scrum adopters in the game industry have adopted an iterative approach to pre-production followed by a detailed production schedule. This is effective, but it does not mean that all the benefits and practices of agile should be dropped when the team enters production. The principles of agile can still help in production.

How Can Agile Help a Production Schedule?

There are benefits of agile that can be employed to help the team and the customers refine the production schedule:

• Iterative production estimates even in pre-production.
  Sprints deliver working software with potentially shippable assets. The team can use the empirical information of the true cost of producing these assets to refine their estimates of making all of the remaining assets of the same type. For example, if the schedule anticipates nine months of production, the team should start verifying that schedule 18+ months in advance of shipping. You don't want to discover that you really need 12 months of production when all you have left is 9.

• A production schedule is just a prediction. It needs refinement.
  Once a schedule for production is in place it should be treated like a prediction given the facts at the time it was created. This prediction should be continually examined and refined. The team should find ways to reduce the cost of production while improving the quality of the assets. More time freed up from production can be dedicated to polishing and tuning during post-production.