CMPS171, Winter 2013, Section 01: 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 is one release, at the end of the quarter, and hence release planning involves identifying goals for the quarter.

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:

  • Playtesting: By the end of Sprint 2, 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 assets. It does mean that the software must deliver some kind of playable experience that is a way station on the road to final implementation of the game design document. This implies that Sprint 2 has a user story that goes something like, "As a playtester, I must be able to play a {minimal subset} of the game."
  • Website: By the end of Sprint 2, there must be a skeleton of the game's website. By the end of Sprint 3, this website must be complete. This means Sprint 3 (or possibly Sprint 2) should have a user story similar to, "As a potential customer, I need to be able to learn about the game and its progress via the game's website".
  • Gameplay metrics: By the end of Spring 3, the game must have internal code that automatically records gameplay metrics, and makes them available to a tool that performs post-test analysis. For example, in a game that has levels and a notion of player death, it would be very useful to record when and where a player dies. This information can then be overlaid on a map of the level to create a heatmap of deaths. This is also a significant activity, and will require at least one and possibly two or three people to be dedicated to this task.

One consequence of these required activities is that Sprint 3 will several team members to be working on required functionality (gameplay metrics, website) and on conducting playtests, hence leaving the team with reduced ability to implement new game features.