The Essential Release Checklist

Release managers often face a chaotic mix of tasks at work and even on their days off. A good release checklist can bring order to the chaos, making it easier to deliver what tech teams proudly call the next best thing since sliced bread.

While we cannot always set a priority, we still need to ensure that we deliver quality stories and features to the customer without disrupting what they already have.

In my experience, implementing quality gates at every step of the process helps to manage the releases well. But those things take time. So, how do we ensure that the next release we approve is of good quality and value?

Release checklists are a powerful tool for release managers; you can find them under different names. For instance, in the Agile world, some call it the definition of done. In ITIL, it is called the Service Introduction checklist. These processes and documents live in isolation in an ideal world, but there is no perfect world. I have the checklist items I maintain for releases, which I have built from my years of experience working on ITIL and agile worlds. Take these checklist items as prompts to dive deeper into the specifics of the release chart and the course of action for each release.

Before exploring the checklist, it’s important to understand the key steps of release management. Our The Release Management Essential Guide provides a detailed overview of the process, from development to deployment, to help you perform each phase with confidence.

Why using Release Checklists?

A quick note on why checklists are needed:

1. Consistency
   With a checklist of your own, you can consistently follow a minimum set of practices and improve them in iterations.

2. Enhanced communication
   With a well-drawn-out release checklist, stakeholders and participants know the steps and align their expectations accordingly.

3. Reduce risk
   A checklist will ensure you don't miss compliance or other governance items needed for a deployment.

A release checklist should be the first document a release manager makes. This document should help the manager understand how it is done at the organization and then iteratively update the document and the processes.

Like every significant project, we must break down the release checklist into smaller tasks. I like to call these domains. The domains are overarching areas of a deployment, which would then have items for the specific release. 

Domains in release management

In my current practice, the following domains are the most relevant.

1. Scope
2. Build
3. Deploy
4. Communicate

I will explain each domain below :

Scope

This domain would have items that validate that the feature/product or service delivered is fit for purpose. Typically, a Product owner or a BA (Business Analyst) would validate the feature and confirm that the behavior is as designed.

This domain answers the following question: "What are we delivering?"

Under the scope domain, I would document the following components for a release:

The scope of the release

It might sound obvious that we should know the scope of the release. However, in real life, many stakeholders have a general idea of what they want to release. A release manager can help answer this by documenting:

1. The user stories or Epics in scope for the release. This discussion with the Product/ stakeholder is usually a robust conversation, as decisions need to be made, and scope items lying on the periphery of the release are usually either absorbed or planned for another day.
2. Interdependencies between the scope items will help us understand which items/ user stories need to be released together and which can be released independently.

The supporting requirements for the release

In a pure tech release, these are usually clubbed as Non-functional requirements. The availability of A/B tests, service response time, and appropriate mechanisms to collect data. It can be argued that such requirements could also be documented in a user story or a task under the user story. That is a valid argument, but this question is essential for two reasons

1. It acts as a safety net for scope items that are not always considered. Every organization has a blind spot, and these questions can try and avoid those
2. Many BAs, Product Managers, and Agile teams focus on the solution they are building. This sometimes means that they lose sight of running the solution in production. For example, we cannot run a new feature without effectively measuring its impact, but often, the teams building a solution bake in analytics after the feature has been released to the customers.

Build

In essence, this domain is about building and validating it against the requirements documented in the user stories/requirement documents and against the performance or Non-functional requirements.

This domain answers the following question: "Have we built properly what we are delivering?"

Under the build domain, I would document the following :

User story / Functionality sign-off / QA Validation

Almost every organization today has a QA team or a function (there are agile teams where developers test their code). Their primary purpose is to validate the product build is aligned with the purpose set out by the product domain. This usually means running Functional, Integration, and Regression tests on a build. As a release manager, you could choose how deep you want to dive into each area.

I have always tried to incorporate user feedback in my release cycles. One way to do that is to look for opportunities to conduct UAT before releases. This is easier when the end users, like operations and logistics teams, are within the organization. I encourage adding a healthy percentage of users to the beta channels for customer-facing apps to get early feedback before we deploy.

Architecture review

In many traditional organizations, this phase is done before user stories are written. With many organizations moving to agile working methods, Architecture reviews are usually done during sprints, sometimes even after the build is complete. As a release manager, it helps me to align with the solution architects regularly to ensure that their inputs are baked into the delivered solutions.

Unit tests, security tests, and similar dev tests

Developers writing unit tests is not a new practice. The challenge has always been their reliability. More often than not, the developer owns the unit tests. Sometimes, the results are also not documented formally.

With the emergence of tools like SonarQube and their integration with CI/CD pipelines, unit testing reliability has improved. However, the quality of unit tests still largely depends on the quality of tests written by the developer.

Data Analytics and Observability pipelines

Data analytics and observability are hard to replicate in staging environments, where most of the testing happens. Hence, these requirements are usually tested or even realized late in the release pipeline.

In the Agile world, it is taken care of in the definition of done (DoD). Such requirements, along with other non-functional requirements, are mentioned in the DoD doc. It is an optional document and a standard a team holds themselves to. Hence, it doesn't guarantee that it will be implemented.

Having such criteria items on the checklist helps a release manager stay on top of the release and prevent post-deployment issues.

Deploy

The deploy domain should have items related to your deployment pipelines.

This domain will help answer the question, "How are we deploying?"

I would document the following:

1. Additional infra or capabilities required for deployment or post-deployment.
2. Any migration activities required during deployment.
3. The impacted users and quantification of impact.
4. The sequence of events during the deployment.
5. Metrics to be monitored post-deployment.
6. Exit criteria for the deployment and beginning of the post-go-live support

A few deployment questions are answered during the earlier stages, but this checklist section can be the fail-safe filter, preventing us from missing out on some of these critical questions.

Communicate

The final domain on the checklist concerns keeping the stakeholders engaged. Maintaining a stakeholder list is an old practice advocated by the PMI, but it is still essential today. A release manager must list all stakeholders, categorize them, and create appropriate communication channels for each category of stakeholders at regular intervals.

This domain answers, “Who needs to know we are deploying?”

The communication section covers,

1. Who is impacted
2. Communication lines according to severity of impact

You should have an additional stakeholder checklist to complement the release checklist “communicate” domain.

Additionally, if you're looking to enhance your team's collaboration, don't miss our recent ebook on mastering communication in release management. It’s packed with strategies to improve stakeholder engagement and ensure smoother deployments.

The above are generic domains under which specific checklist items reside and are prompts for a release manager to add to the checklist. 

I have used variations of release checklists in my previous two organizations. I used it as a starting point to understand the how and what of the project and then moved it to Jira. We've created this release checklist to benefit other release managers, making it easier for you to adapt it to your own context. Feel free to add or remove items based on your specific needs to make the most of it.

While Excel is an excellent tool for managing releases, Jira and Confluence makes life easier by creating checklist items and process flows closer to where the teams work.

Key Takeaways

A release checklist can prove a handy chink in the armor of release managers to understand and set the release processes for an organization.

Once the release process is stabilized, the release checklist also acts as a handy requirements list for building your automation. Jira is the perfect tool for that. If you want to know how Jira can be used for managing releases, I recommend reading the article 7 Steps to Implementing a Release Process with the Atlassian Suite, EazyBI and Golive,