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).

There are some requirements that each team must satisfy in their release planning. These are:

• Core Loop Release: For the Core Loop release, the game must be in a state such that a playtest can be performed. This does not mean the game must be complete, or have all art and sound assets. But, the game must have the player avatar represented in the final art style of the game. The environment should include some amount of art consistent with the chosen art direction. The control scheme for the avatar must be in place. Music and limited sound effects consistent with the game's art direction must be in the game. The software must deliver a playable experience that is reflective of the final gameplay feel. Each game will be evaluated based on its Core Loop Release. 
  
• First Playable Release: For the First Playable release, the game must have player avatar behavior fully defined, enemy/obstacle behavior fully defined, basic technology done, and two complete levels at a near-final state. This includes final art for these levels, and final music and sound effects for these levels. It must be possible to play the game and evaluate the potential of the game as an enjoyable entertainment experience. Each game will be evaluated based on its First Playable Release.
• Website: By the end of Sprint 3, there must be a skeleton of the game's website, and one or more social media pages. By the end of Sprint 4, this website must be complete, and any associated social media sites must also be published. This means Sprint 3 and Sprint 4 should feature user stories similar to "As a potential customer, I need to be able to learn about the game and its progress via the game's website and social media".

One consequence of these required activities is that Sprint 4 will have several team members to be working on required functionality (website, social media), hence leaving the team with reduced ability to implement new game features.