Exploring the Release Phase of a Scrum Project

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK?). The Release phase is the final stage of a Scrum project.

This phase includes two processes that emphasize delivering the Accepted Deliverables to the customer and identifying, documenting and internalizing the lessons learned during the project. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.

Ship Deliverables

In this process, Accepted Deliverables (those that meet the Acceptance Criteria and Definition of Done) are delivered or transitioned to the relevant stakeholders. To get formal customer acceptance is critical for revenue recognition; the responsibility for obtaining it will be defined not necessarily by the Product Owner but by the company policies. This process marks the final shippable deliverable for which the project was sanctioned. As new product increments are created, they are continually integrated into prior increments, so there is a potentially shippable product available at all times throughout the project. The Product Releases should include Release Content, which consists of essential information about the deliverables that can assist the Customer Support Team, and Release Notes, which should include external or market facing shipping criteria for the product to be delivered.

Retrospect Project

In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements to be implemented in future projects. The primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Additionally, the Scrum Guidance Body may provide expertise in various areas including Quality, HR and Scrum. When the initial Program Product Backlog or Prioritized Product Backlog are developed they are based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review, Retrospect Sprint or Retrospect Project Meetings. These items should be added to the Program Product Backlog (for the program) and Prioritized Product Backlog (for the project) as they are discovered.

Executing the two processes of the Release phase ends a project in successful fashion—one that satisfies all parties involved. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. In the Release phase, assuming all of the prior phases of the project were followed, the Scrum Team can enjoy a job well done while keeping in mind lessons learned for future projects.