Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Approve for Release-OLD

Updated on July 18, 2019

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. This 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.



In preparation for this meeting, it is very important to determine who the key stakeholders and decision makers are that need to attend. 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.


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


Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us