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.
- 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.
(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
"ITSN - Release 14.10 - Split-Match" (This would be the October 2014 release from the ITSN Team)