Release Plan

See also: template, evaluation

The goal of release planning is to identify the high-level goals and the medium-level goals for the next release of the software. For Game Design Studio II, there are two releases, at the end of the second sprint (Core Loop Release), and at the end of the fourth sprint (end of quarter) (First Playable Release), and hence release planning involves identifying goals for each release in succession.

Unlike some agile development contexts, in this class your release schedule and sprint durations are tightly timeboxed. That is, you have no control over the duration of sprints, or when the release occurs, as these are given to you. This means you need to pick a set of goals that are realistic in the time provided.

Done properly, release planning is performed in a meeting that can last many hours. Determining the features for a release can be hard, since it involves thinking through all of the possible capabilities of your game. Release planning also involves deciding to push some features off until later, which might mean Spring quarter, or might mean never. If a feature makes it into the Winter release, it's in for sure. This, in turn, requires prioritizing game features; it's not sufficient to say "everything is important". This may be true, but in a fixed-length time situation, a team must decide on an order in which to implement features. Another complication is dependencies among different technologies in use in a game. For example, it may not be possible to have game levels before a level design tool is complete.

A team is its own worst enemy when it comes to crunch times. If your team makes accurate time estimates and correctly scopes the release features to the capability of the team to perform them, it is possible to avoid implementation deathmarches right before the end of a sprint. The two main ways teams sign themselves up for horrible crunch times is by under-estimating the time required to implement features, and allowing too many features into the release. Failure to evenly pace activity throughout a sprint also results in crunch time.

Since teams will need to prioritize high level goals and user stories (features) during their release planning meeting, a good practice is to write the high-level goals and the the user stories on post-it notes or index cards, and put these on the wall (one location for high-level goals, one location for user stories), in priority order. This will help the team to see the complete set of all goals and user stories, and better reason about relative priorities.

Teams will need to estimate how much time each user story will take to implement, using story points. Teams should use the planning poker technique to perform task estimation, and hence each team should make sure they have a set of planning poker cards prior to the start of their release planning meeting (planning poker cards will be available in the lab).