Coordinating releases with development teams

‍Product Ops Assistant & Product Leader

‍Meet to review the current product release process, including release cycle cadence (e.g., sprint deployments), pre-release actions (e.g., user acceptance testing, regression testing, merging environments), and how releases are currently coordinated. Identify any pain points related to product releases.The Product Leader may guide the Product Ops Assistant to relevant team members for further insights. ‍

Product Ops Assistant

‍Engage with relevant team members to gain a thorough understanding of the current release process. This includes discussions with development team members to identify their needs, as well as with QA, product managers, product owners, scrum masters, and marketing teams involved in releases.

Product Ops Assistant

Create a document outlining all required steps in the release process, including any new steps identified as necessary. This document will serve as a template to finalize a release-specific checklist each release cycle with assigned owners for each task. Key steps might include:

Define release contents: A product manager, lead developer, or other relevant team member clearly defines the features and bugs to be included in a release. The team should identify and note any dependencies.
Set a feature freeze date: A date beyond which no new features may be added is established.
Complete user acceptance testing: User acceptance testing by a product manager or key stakeholder is completed before final approval of a product update is given.
Merge environments: The development team completes their procedure for merging environments and resolving code conflicts, preparing for regression testing on a final environment.
Complete regression testing: Final regression testing in an environment as close to production as possible is completed.
Prioritize bugs and approve deploy: A product owner or manager categorizes any final bugs that come out of regression testing to determine whether they are deploy blockers or not. Once all final deploy blockers are addressed, deployment is approved.
Complete deploy tasks: The development team documents and completes deploy tasks, with one key developer responsible for ultimate approval.
Complete admin tasks: Any admin tasks that may need to be completed by a Product or Content Manager for a specific release (eg. enabling an experiment or feature flag) are accomplished.
Send out release communications: Communications about product updates are sent to internal and external stakeholders. Refer to the "Product communication: Developing a communication plan for product updates" playbook for more details.
Document product updates: Both internal and user-facing documentation is updated to reflect the new features introduced in the release. This might include internal knowledge bases, customer support resources, user manuals or guides, and marketing and sales collateral.
Measure release health metrics: Key metrics, such as deployment success rates, rollback frequency, and user feedback post-release are measured, so that they can be evaluated during retrospectives.

Ensure that relevant teams have more detailed documented procedures for each step, as necessary. For example, the development team should maintain a documented procedure for merging environments and for deploying. The QA team should maintain a detailed regression testing plan.

In addition to defining steps in the process, consider the following:

Release cadence and communication: If possible, work to establish a regular release cadence that the entire team is aware of (e.g., deploys at 1 PM on Thursdays). When setting this schedule, consider any times or days that might be inconvenient for clients or the internal team. If your data indicates periods of high product usage, avoid scheduling releases during those times. Additionally, be mindful of seasonality and avoid planning releases close to times when many team members may be out of office, such as during holiday seasons. If a regular release cadence isn't feasible, ensure that release dates and times are communicated clearly and well in advance, giving all relevant team members ample notice. Consider creating a shared release calendar to keep everyone aligned and informed.
Risk plans: Ensure that the engineering team has a rollback plan in place in case of release issues, and confirm that these plans are regularly tested. Capture any non-technical steps that need to be taken as a part of the rollback plan (for example, communication to stakeholders and customer support). Decide on alternate timings for especially risky releases (e.g., weekends, after hours). Prepare emergency communication plans, like a “maintenance banner” that displays on the website or customer/vendor emails.
Release coordinator: Designate a key developer as your primary point of contact. If no one else already performs this role, take on the role of release coordinator yourself to manage communication, track progress, and ensure alignment across development teams.‍

Checklist.gg has a comprehensive release planning checklist you can leverage when creating your own release process document. Smartsheet also offers extensive advice and templates for release planning.

Coordinating releases with development teams

Overview

Result

Process