Sprint and Release Duration Policy

EFFECTIVE DATE: October 6, 2016

APPROVED BY: Mike McCoy

LAST UPDATED: August 30, 2022

PURPOSE

The purpose of this policy is to ensure the sprint and release duration(s) used to manage software centric products and services developed within InnovaSystems, International LLC (ISI).

SCOPE OF THE POLICY

This policy defines the standards for planning and execution period and is applicable to all ISI software development project teams developing software business solutions and services.

APPLICABILITY

Project Managers have the responsibility for planning and executing sprint and release cycles. Project Leads must ensure the team is adhering to this Sprint and Release Duration Policy. Project personnel must comply with this policy by planning, executing, and reviewing short development and release cycles.

AUTHORITY AND COMPLIANCE

This policy is authorized by the Chief Operating Officer (COO). Compliance to this policy will be evaluated through an appraisal/audit process. Results will be provided to the appropriate personnel and non-compliance/issues will be submitted to the Business Unit Leads and the Executive team for remediation.

POLICY STATEMENT

This policy is intended to establish Sprint and Release expected durations. Releases are typically composed of multiple sprints and allow for the combined completion of significant portions of Azure Dev Ops features. Releases can be deployed into test, integration, or production environments. Completed features are placed in a resolved state when going to pre-production environments. Completed features are placed in a closed state when going to their first production environment.

Sprint and Release durations shall:

  1. Plan short sprint cycles not to exceed three (3) weeks in length. This does not apply to the release of software or services, only to the planning, execution and review of project work.

  2. Plan and schedule releases based on the projects’ Release Strategy not to exceed twelve (12) weeks in length, choose either one of the following:

    • Scope-based (Functionality).
    • Time-based (Date Sensitive).

  3. Request written authorization from the COO for special case variations to extend sprint cycles beyond three (3) weeks. These will be authorized in writing on a case-by-case basis.

  4. Request written authorization from the COO for special case variations to extend release cycles beyond twelve (12) weeks. These will be authorized in writing on a case-by-case basis.

Process Guidance Version: 10.4