Release Plan Template

At the end of your team's release planning meeting, the team needs to turn in a release plan. Release plans are submitted by placing a document into your team's process folder in the shared Team Drive for the class. This document needs to have the following elements:

• Heading: Document name ("Release Plan"), game name, team name, release name, release date, revision number & revision date.
  
  
• High level goals: A description of the top-level goals for the release. Examples include, "Be able to play one complete level (but with limitations xx, yy, & zz)," "Have all controller capabilities implemented," "Be able to create levels using a level design tool." These high-level goals may map to a single user story, but more typically will map to multiple user stories. The release functionality that is required by CMPM 171 (playtesting, continuous integration, gameplay metrics, website) must be listed as high level goals in this section of the document. High level goals must be listed in priority order, from highest (top) to lowest (bottom).
  
  
• User stories for release: A listing of all the user stories that are needed to implement the high level goals. Each user story must have a story point time estimate. Each user story must be assigned to a Sprint, and within each Sprint, listed in priority order from highest (top) to lowest (bottom). Recall that there are 4 Sprints in this class, 2 per release. Each high level goal should have one or more user stories associated with it. User stories that do not correspond to a high level goal, or a high level goal that has no associated user story, are both indications of a lack of project specification.
  
  Recall that a user story should take the form, "As a {user role}, I want {goal} [so that {reason}]". A user story should fit on an index card, and meet the "INVEST" criteria (independent, negotiable, valuable, estimatable, sized appropriately, and testable).
  The complete list of user stories will take the form of:
• Sprint 1
  (story points) User story 1 (highest priority for Sprint 1)
  (story points) User story 2
  ...
  (story points) User story N (lowest priority for Sprint 1, but might get bumped down into Sprint 2 if not implemented in Sprint 1)
  
  
• Sprint 2
  (story points) User story 1 (highest priority for Sprint 2)
  (story points) User story 2
  ...
  (story points) User story N (lowest priority for Sprint 2, but might bump down to Sprint 3)
  

• Product backlog: A listing of all high level goals and user stories that were discussed in the release planning meeting, but which did not make it into the release. This can be used as a starting point for planning the next release, in Spring quarter. If this section is empty, there should be an explanation for why this is the case (as this is atypical).