One of the common misunderstandings of agile is that it avoids any long-term planning in favor of only planning a few weeks out. What agile does not do is support highly detailed long term plans up front. Agile methodologies, like Scrum, focus on continual planning for the entire range of the project. Like the iterations on the project itself, agile continually returns to the assumptions of the plan and modifies it based on reality.One of the principles of Scrum is that the team commits to the amount of work they feel they can finish in small iterations of time called Sprints. These iterations are typically two to four weeks in duration. The results of the last Sprint will be used to potentially modify the goals and priorities of what will be worked during the next Sprint. This allows the goals of the project to "drift" a bit every few weeks. Ideally this drift is for the benefit of the game.

Planning and Scrum are not incompatible, but the particulars of when to plan and how much to plan at once change quite a bit when switching to Scrum. Publishers and developers cannot replace detailed plans and schedules with anything but frequent communication.Long term agile planning has been greatly enhanced by the practices that Mike Cohn has introduced in his book Agile Estimating and Planning, and in the courses he provides through Mountain Goat Software. These practices give teams additional tools to apply in predicting how much work can be done further out in the future, while still allowing an agile project to introduce change.

One major benefit gained from transitioning from deterministic schedules to iterative planning cycles is that the customers assume more control over the schedule and budget by manipulating the scope. This is done by continually prioritizing the list of features that they want in the game (called the product backlog) based on what value is emerging from the real game. The team delivers these features on a regular basis.If the customer decides that the features built up are sufficient for the money spent or if the fixed delivery date demands, then the team can move over to building the production assets and completing the game. The benefit of this approach is that features of less importance to the game are abandoned before a great deal of effort is spent on them. This is in contrast to having the schedule or budget force the decision to cut key features that might be 90% complete.Schedules often don't predict many of the problems which slow down development and don't prioritize the work based on value. Instead they try to optimize the resources to work in parallel and define when everything will complete at the same time. In reality, these parallel efforts rarely stay in pace with one another and the cross-dependencies can slow the entire effort down. This leads to team death marches and critical features being cut in order to meet a delivery date.