A release is a deployable software package that is usually the culmination of several iteration cycles of incremental deliverables, and/or those iterations as a group. A release can be internal or external.

General Guidance

• Each release must be baselined prior to starting. This means that all features, themes, initiatives, and/or program epics must be defined prior to the start of the release. It is a responsibility of the TSD PM to ensure that the release is planned and started on time.
• All releases should follow a cadence that maps to a calendar month. Starting on the first day of a month, and ending on the last day of that or a subsequent month.
• Regular releases may not be longer than 3 months, and should not be shorter than 1 month.
• Regular releases occur off hours and outside of normal sprint planning.
• Releases should be named based upon the calendar month of the release. Features must be assigned to release.
• User Stories must be at least defined in order to place in a release.

Naming Conventions

(PROJECT TEAM CODE) - “Release” (RELEASE NUMBER) - (UNIQUE NAME)

• Project Team Code: Should be the short name or acronym for your project team. Examples include “AcQNav”, “ITSN”, and “FAaaST.”
• Release Number: The Release Number refers to the Calendar Month and year of the last month of the release cycle. For example, if your doing a quarterly release for the 1st calendar quarter in 2014, the release number would be 14.3. 3 refers to March, which is the last month in the release cycle. Release Number is prefixed with the word “release” for reporting purposes to prevent confusion with sprints..
• Unique Name: This can be any text to help the teams better define a Release. It is not required

Example:

"ITSN - Release 14.10 - Split-Match" (This would be the October 2014 release from the ITSN Team)