Agile Scrum Methodology: Sprint 1-n Process

PURPOSESCOPEPROCESS DESCRIPTIONPROCESS INPUTS/OUTPUTSSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owners: Manager, Business Relationship Management, and Manager, Solutions Development and Support

Note: An owner must be a PCES-level manager.

This process establishes standard processes for the Technology Solution Life Cycle (TSLC) Agile Sprint 1-n phase within the Postal Service Technical Environment.

PURPOSE

The Sprint 1-n phase is an iterative development process that includes the Sprints that have been identified during the Sprint 0 Release and planning to complete all functional and nonfunctional User Stories that have been identified for that Release. For a Sprint, each User Story may have further requirements and design defined, build created, and System Integration Testing (SIT) and Customer Acceptance Testing (CAT) performed.

For all steps in the Sprint 1-n phase:

The processes within the Sprint for each User Story are:

The Sprint Planning process reviews those User Stories identified for that Sprint and defines any further requirements and design, creates the tasks and hours for each to complete, revalidates the project plan and schedule, and temporarily stores any created TSLC deliverables (additional requirements and design). The objectives for Sprint Planning are:

The Sprint Build process develops product functions and features based on the requirements and designs that have been defined and approved for each User Story. The objectives of the Sprint Build are:

The Sprint SIT process validates that the build solution meets the requirements for the User Stories for that Sprint prior to the Sprint CAT. The objectives of the Sprint SIT process are as follows. These actions are typically performed by the development team but may be performed by other members of the project team:

The Sprint CAT process validates that the build solution meets all of the documented requirements for the User Stories for that Sprint. The objectives of the Sprint CAT process are:

The activities for each of these Sprint processes are performed for every User Story within every Sprint that has been identified within the project plan.

The Sprint Retrospective process reviews the activities and outcomes at the end of each Sprint. It is performed with the entire project team. The objectives of the Sprint Retrospective are:

After all Sprints have been completed:

SCOPE

This process applies to all:

Exemptions:

Note: The approved, signed SIT/CAT Exemption_Post-Production Review (PPR) Form must be uploaded to the project in the TSLC Artifacts Library (Release phase / IT Change Request folder) before implementation.

PROCESS DESCRIPTION

Notes:

Each Sprint is composed of the following sub-processes:

Sprint Planning

Sprint planning includes the activities outlined in this section.

  1. Plan Certification and Accreditation Activities.
  2. The Business Relationship Management Program Manager (BRM PM) coordinates this task.

    For security-related processes and artifacts, follow the Certification and Accreditation Process as described in the Handbook AS-805A, Information Resource Certification and Accreditation Process.

  3. Clarify Technology Solution Requirements.
  4. The BRM PM coordinates this process.

    1. Review/clarify Requirements.
    2. Update the Requirements to clarify requirements for each Sprint (1-n).

    3. Review changes to Requirements.
    4. The Technology Solution Coordinator (TSC) coordinates review by all Solution Stakeholders, as defined in the Change Control Board (CCB) Document, for validation of the requirements developed during the Sprint for each User Story.

    5. Approve clarification to Requirements.
    6. Sprint requirements are reviewed and any changes are approved by the CCB. Documentation of approval is provided with the completion of (Release) CAT.

  5. Update Technology Solution Design Documents.
  6. The BRM PM coordinates this process.

    As appropriate, host designs, database designs, network designs, application designs, etc., are developed/updated based on the Requirements that were approved in Sprint 0. Host designs may use the TSLC template. All Technology Solution designs will encompass those environments that have been defined within the scope of the Technology Solution requirements.

  7. Perform Design Walkthrough with All Appropriate Technology Service Providers.
  8. The BRM PM coordinates this process.

    All Technology Service Providers who have a stake in the Technology Solution will bring their draft designs to a walkthrough session. The designs will be reviewed against the requirements, and approval must be obtained by the Enterprise Architecture Committee for all projects introducing new or expanded use of IT services, Technology Solutions, or COTS software. This review process also applies to projects that require upgrades to software previously approved for inclusion. The objective of the walkthrough is for all IT Service Providers to agree on the design. Any changes to the Technology Solution requirements as a result of the design must go through the CCB.

  9. Develop Sprint CAT Scripts.
  10. The BRM PM coordinates this task.

    The Sprint CAT scripts are documented test scenarios that outline input data, sequence of test steps, and expected output values. The Sprint CAT scripts define the Technology Solution acceptance criteria. Once the test scenarios have been developed, the CAT team will walk through all scenarios to ensure that requirements are thoroughly tested.

  11. Update the Technology Solution Implementation Costs.
  12. The BRM PM coordinates this task.

    The collection of cost estimates from all IT Service Providers who have design input into the respective technology solution.

  13. Review the Impact Assessment(s).
  14. The BRM PM reviews the SOX Impact Assessment (SIA) and/or PCI Impact Assessment (PCI-IA) to determine whether changes that have been made impact the assessment. If changes do impact the assessment, update and resubmit the Impact Assessment(s). If the Impact Assessment(s) is updated, it must be submitted to the respective CCB (SIA to SOX CCB and PCI-IA to PCI CCB) at least 30 days prior to implementation. Changes with a planned implementation date within the high-risk period must be submitted at least 45 days prior to the implementation date.

  15. Assess for Significant Updates to Design.
  16. The BRM PM coordinates this task.

    If there is a significant update to design, EA Checkpoint 2 for the entire Technology Solution must be reviewed and approved prior to the (Release) SIT phase. EA Checkpoint 2 serves to ensure adequate completion, review, and approval of the TSLC inputs provided before approving a proposed technology solution.

  17. Tollgate Process Only: Obtain Stakeholder Consensus Approval for Requirements.
  18. The BRM PM coordinates this task.

    If Stakeholder consensus approval is provided for all sprints as described in the TSLC Policy, the Finalize Release Tollgate meeting is not necessary.

Sprint Build

Sprint build includes the activities outlined in this section.

  1. Develop and Unit Test Technology Solution.
  2. The TSC coordinates this process.

    This process develops and independently tests individual components necessary to deliver the Technology Solution. Individual components may include procured items such as COTS. The extent of integration testing of the components at this phase is dependent on the TSC.

  3. Develop Build Plan.
  4. Each service provider will develop its own build plan that maps to its tasks that were developed in the Sprint Planning phase.

  5. Validate and Approve Build.
  6. This QA process validates that Technology Solution components are built according to specification and that proper software version and infrastructure hardware are installed prior to progressing to the SIT phase. Upon validation by all TSP stakeholders, configuration management records are updated to reflect the Technology Solution.

  7. Develop Sprint SIT Scripts.
  8. The Sprint SIT scripts are documented test scenarios that outline input data, sequence of test steps, and expected output values, which could be on screen, in reports, etc. Once the test scenarios have been developed, the SIT team will walk through all scenarios to ensure that requirements are thoroughly tested.

    This process includes the following steps:

    1. Identify possible threats that could adversely affect the business solution.

    2. Identify security vulnerabilities that could be exploited by threat events affecting the business solution.

    3. Analyze implemented and planned controls against requirements.

    4. Identify the probability that vulnerability may be exploited.

    5. Identify the adverse impact resulting from a successful exploitation of vulnerability.

    6. Identify possible additional mitigating controls that, if applied, could be expected to mitigate the risks identified for the business solution.

    7. Document the overall risk status of the business solution.

Sprint System Integration Testing (SIT)

Sprint SIT includes the activities outlined in this section.

For each Sprint, the project team will conduct a Sprint SIT to ensure that the functionality developed for that Sprint functions as designed. In addition, at the end of all of the Sprints for that Release, there is a (Release) SIT phase to ensure that any design problems for the entire release are identified. During each Sprint Review, an end-to-end integration test is not required. However, the Team(s) must ensure end-to-end SIT is performed for the (Release) SIT phase. SIT scripts, SIT results, and SIT approvals are required for each development Sprint and for the final Release. Baseline artifacts must be retained for the (Release) SIT.

  1. Assess for Significant Update to Design.
  2. If there is a significant update to design, EA Checkpoint 2 must be reviewed and approved with each applicable Sprint.

    EA Checkpoint 2 ensures adequate completion, review, and approval of the TSLC inputs provided before approving a proposed technology solution.

  3. Update Sprint SIT Strategy.
  4. To update the Sprint SIT Strategy, the Draft SIT Strategy will be revisited and updated where appropriate with the most current information available.

  5. Finalize the Sprint SIT Scripts.
  6. Finalize the Sprint SIT Scripts to ensure that requirements are thoroughly tested.

  7. Create Sprint SIT Plan.
  8. The Sprint SIT Plan will include all steps necessary to perform Sprint SIT. This includes when and who will exercise which scripts, which system jobs will be run, which system backups, which security procedures will be followed, etc.

  9. Perform Sprint SIT.
  10. Execute the Sprint SIT Plan. All Sprint SIT results are documented on the scripted materials, identified as problems on the problem log, or identified as new requirements on the enhancement log. All test results should be retained in accordance with Postal Service data retention requirements.

  11. Analyze Sprint *SIT Results.
  12. Review the Sprint SIT results and determine if the Technology Solution meets the Technology Solution Requirements and Sprint Planning. Problems identified in testing will be categorized and documented in either a problem or an enhancement log. If the issue results in a change to the accepted Technology Solution Requirements or Design documents, it will be logged and submitted to the CCB. Problems will be entered, prioritized, and resolved prior to the CAT process. This is a Baseline requirement, for all SOX in-scope and out-of-scope systems, that must be stored in the TSLC Artifact Library.

  13. Review Sprint Requirements.
  14. Review Sprint requirements to ensure that approved business owner (customer) Requirements still map to Technology Solutions and Sprint Test scripts and results.

  15. Obtain *SIT Approval.
  16. The purpose of this activity is to create a checkpoint and gain acceptance of the as-built tested Technology Solution. The accepted Technology Solution may now begin its migration to the Sprint CAT environment through the Release Management process.

    Note: Sprint documented approvals are included in the (Release) SIT phase.

  17. Revise SIT Strategy for the Release.
  18. To create the SIT Strategy for the Release, the Draft SIT Strategy will be revisited and updated where appropriate with the most current information available. The SIT Strategy will include current information from the Technology Solution Requirements, Design, and Build.

Sprint Customer Acceptance Testing (CAT)

This portion of the sprint is composed of the following subprocesses.

At the conclusion of every Sprint, the Team will conduct a Sprint Demo and/or Review with the business owner (customer) to ensure that the functionality for the Sprint satisfies system requirements. This Sprint Demo and/or Review serves as the Sprint CAT. Business owner (customer) acceptance of functionality during the Sprint Demo and/or Review satisfies the Sprint CAT requirement. An end-to-end integration test is not required during each Sprint Demo and/or Review.

At the end of the Project, the Team(s) must ensure that end-to-end testing is performed for the CAT phase to ensure that the entire Technology Solution satisfies the functionality, user experience, and performance requirements of the business owner (customer). Baseline artifacts must be retained for the CAT phase. This process is composed of the following subprocesses:

  1. Update Sprint CAT Strategy.
  2. To create the Sprint CAT Strategy, the Draft CAT Strategy will be revisited and updated where appropriate with the most current information available. The Sprint CAT Strategy will include current information from the Technology Solution Requirements, Design, Build, and SIT.

  3. Finalize Sprint CAT Scripts.
  4. Finalize the Sprint CAT Scripts to ensure that they are ready for Sprint CAT.

  5. Create Sprint CAT Plan.
  6. The Sprint CAT Plan will include all steps necessary to execute Sprint CAT. This plan will include when the scripts will be executed, who will exercise which scripts, which system jobs will be run, which system backups, which security procedures will be followed, etc. This is an hourly/daily project plan that outlines the sequence of events for all tasks performed during Sprint CAT.

  7. Perform Sprint CAT.
  8. Execute the Sprint CAT Plan. All Sprint CAT results and Post-Implementation Review will be documented on the scripted materials, identified as problems on the problem log, or identified as new requirements on the enhancement log. All test results will be retained in accordance with Postal Service data retention requirements.

  9. Analyze Sprint *CAT Results.
  10. Review the Sprint CAT results and determine if the Technology Solution meets the system requirements. Problems identified in Sprint CAT will be categorized and documented in either a problem or enhancement log. Enhancements will be submitted to the CCB for processing. Problems will be logged and submitted to the TSC for resolution and then planned for retesting. This is a Baseline requirement, for all SOX in-scope and out-of-scope systems, that must be stored in the TSLC Artifact Library.

  11. Review Sprint Requirements.
  12. Review Sprint Requirements to ensure that business owner (customer) Requirements still map to Technology Solutions and Sprint Test scripts and results.

  13. Obtain Sprint *Business Owner (Customer) Acceptance Approval.
  14. The executive sponsor and portfolio manager review the accreditation letter, risk mitigation plan, and supporting Certification and Accreditation (C&A) documentation package. They will issue a joint decision on whether to release the Technology Solution Sprint and with what restrictions, if any.

    Note: Sprint documented approvals are included in the (Release) CAT phase.

  15. Revise CAT Strategy for the Release.
  16. To create the CAT Strategy for that Release, the Draft CAT Strategy for the Release will be revisited and updated where appropriate with the most current information available. The CAT Strategy will include current information from the Technology Solution Requirements, Design, Build, and SIT processes.

Complete Certification and Accreditation Activities

The BRM PM coordinates this task.

For security-related processes and artifacts, follow the Certification and Accreditation Process as described in the Handbook AS-805A, Information Resource Certification and Accreditation Process.

Tollgate Process Only: Conduct Finalize Release Tollgate

If the release has been selected for the Tollgate process and Stakeholder consensus approval has not been received for each Sprint as documented in the TSLC Policy, the third Tollgate meeting will take place at the end of the Finalize Release phase of Sprints 1-n.

The following documentation must be updated and presented to stakeholders during the Finalize Release Tollgate meeting:

Documented Tollgate Meeting Minutes and Documented Stakeholder Approval to Proceed are outputs of every Tollgate meeting.

Sprint Retrospective

  1. Identify what went well in the Sprint and can be leveraged for future Sprints.

  2. Identify what could be improved in future Sprints to make the project more efficient and productive.

PROCESS INPUTS/OUTPUTS

Baseline artifacts are mandatory and must be uploaded prior to release to production unless the project is following the Tollgate process. If Tollgate, documents from the Tollgate must be uploaded within 10 business days of the Tollgate meeting. Baseline artifacts are indicated in this document by an asterisk (*).

Inputs

Outputs

For each Sprint:

For all User Stories in each Sprint:

Additional:

SUPPORTING DOCUMENTATION

Access supporting documentation from ITWEB (Internal):

Access Supporting Documentation from USPS.com (external):

REVISION HISTORY

Version
Date
Description of Change
1.0 01.24.2012 Initial release.
2.0 07.10.2012 Scope, Supporting Documentation:
Provided link to SIT-CAT Exemption and Post-Production Review (PPR) Process.
3.0 FY12/Q3 This document was made Section 508 compliant and was converted to HTML.
4.0 02.19.2013 Updated to align with current Agile Methodology and address organization changes. Broke out Sprint 0 into separate process.
5.0 05.10.2013 Updated for Tollgates, PCI, and general compliance; ownership of TSLC processes transferred from Manager, Solutions Development and Support, to Manager, Business Relationship Management.
5.1 08.16.2013 Scope, Process, Inputs and Outputs:
Updated to clarify that the Requirements must be approved, not the Requirements Traceability Matrix document.
5.2 10.15.2013 Scope:
Removed references to the Freeze Waiver as this is a Change Management requirement, not a TSLC requirement.
5.3 03.18.2014 Replaced "customer" with "business owner (customer)" where customer refers to a role and not the TSLC phase.
5.3.1 06.15.2015 The annual review for functional accuracy and current PCI DSS requirements has been completed: No changes. CR 81805
5.3.2 06.26.15 Non-substantive update: Update CR for annual review. Remove link and version of PCI DSS.
5.3.3 03.14.2016 Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 154951
5.3.4 10.31.2016 Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 223948
5.4 05.03.2017 Artifacts were updated as a result of the 2016 Lean Six Sigma effort to improve the TSLC process (approved by Manager, Business Relationship Management and Manager, Solutions Development and Support):
  • The Requirements Traceability Matrix (RTM) is no longer a required artifact. Customer business requirements with approval replace the RTM and eliminate the need to upload redundant information.
  • SIT and CAT scripts are combined with the SIT and CAT results and are no longer required as standalone artifacts.
  • Artifacts are now uploaded to the Release phase / IT Change Request folder prior to release to simplify navigation and increase efficiency.

Process Owner: Added Manager, Solutions Development and Support.

Removed references to Waterfall methodology. CR 269601
Powered By OneLink