Table of Contents

Approve for release

Before any product is released into production, the Scrum team and key stakeholders meet to review testing results, open defects, key residual risks, the transition readiness plan (refer to ‘Handover to BAU’), and any additional open issues to determine whether they accept the solution as built. This is commonly referred to as the “go/no go” meeting because they determine if the release is a “go” or not. It is a critical meeting to ensure that the product has been adequately tested and deemed “ready for use” by the key stakeholders and the Scrum team.


The criteria for a “go” decision should be well documented in advance and reviewed with key stakeholders to align on expectations. The criteria may be different for each release, depending on release goals and any expected benefits which have been previously defined. The conditions of satisfaction should be well articulated and understood by the decision makers.


The formality level varies across industries and organizations, but the release approval process is often needed to satisfy a regulatory or industry mandated requirement. It may also be required by an internal control or gate required by the company. At a minimum, its purpose is to confirm that all parties are confident and prepared for the release.


You will host the approval for release meeting. In preparation for this meeting, it is very important to determine who the key stakeholders and decision makers are that need to attend. Attendees should include project leads, business representatives, test leads, solution architects, and up and downstream system owners.

During the meeting, you’ll review the release goals and acceptance criteria, as well as any open defects, issues, and unmitigated risks. The process for handover to business as usual, including relevant knowledge transfers, documentation, training, and end-user communication should also be prepared and reviewed as part of this meeting. Finally, the specific steps to deploy the application to production and who will do what needs to be documented and reviewed. Any post go-live testing and other validation should be well defined with the appropriate time tables associated so that everyone is aware that the solution is in production and ready for use. For an example go/no checklist please click here.

Contingency planning and fallback planning are recommended in the event that there are post-production issues and the solution has to be rolled back from production.

Suggest Edit

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.