- Each sprint must be baselined prior to starting. This means that all user story definitions and planning must be done prior to the sprint starting. It is a responsibility of the TSD PM to ensure that the Sprint is planned and started on time.
- Sprints must have one of the following cadences:
- Monthly sprint – Starts on the first day of the Month and ends on the last day.
- Twice a month sprint - This includes 2 equal length sprints that are performed in a single month. Sprint 1: 1st – 15th of a month, Sprint 2: 16nd – 30th of a month
- Sprints must align to a Release.
- Sprints may be re-baselined, but must not break normal time-box. So if a re-baseline is performed mid-sprint, the re-baselined sprint can only be a half-sprint long.
- Team member capacity must be determined during sprint planning. Team member capacity should be based upon 85% of committed work hours.
- Team members should not be assigned more that 100% of their available capacity.
- Sprint re-baselining must be approved by the Business owner and TSD Branch Chief.
Managing Unfinshed Work
Please see Unfinished Work section.
Sprint Naming Conventions
(PROJECT TEAM CODE) - “Sprint” (SPRINT NUMBER) - (UNIQUE NAME)
- Project Team Code: Should be the short name or acronym for your project team. Examples include “AcQNav”, “ITSN”, and “FAaaST.”
- Sprint Number: The Sprint Number refers to the Calendar year, month, and “part” of the sprint. For example, if your doing twice monthly sprints and this is the second sprint of the of October 2014, the release number would be 14.10.2. Sprint Number is prefixed with the word “sprint” for reporting purposes to prevent confusion with Releases.
- Unique Name: This can be any text to help the teams better define a Release. It is not required.
Example:
"ITSN - Sprint 14.10.1 - WAN Reports" (This would be the October 2014 Sprint from the ITSN Team)