The Release (Planning) Checklist 🚀

A tool to decentralize release planning and foster self-organization

Early in my career as a Product Manager I soon found myself also being the release manager — having to organise and manage the release and tasks associated with it. This didn’t feel like the best use of my time.

I was by no means a release management expert.

Years later, I now coach Product Managers and have seen this pattern play out at half a dozen different companies all over the world.

I hear common complaints from Product Managers:

“Release planning is a major timesuck”
“We don’t have Release Managers so it falls onto me, as the Product Manager”
“Engineering aren’t pulling their weight”

Being a strong believer in fostering self-organization and empowering those with the best knowledge to make the decision, I have found an effective solution that encourages collaboration and shared accountability over having a dedicated ‘release person’.

I call it, the ‘Release Checklist’.

Why you should avoid having a dedicated ‘release person’

A common trap is to have a dedicated Release Manager or person who facilitates the release. Why? There is a concept known as the ‘bus factor’. The bus factor is where you have single points of failure because you are dependent on one person’s knowledge or capability.

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “in case they get hit by a bus”. — Wikipedia

In the scenario of a dedicated release manager, what happens when that person is away, sick or quits? Who in the team is has the knowledge and is capable of facilitating the release in their absence?

The answer to this is commonly; “no one”.

This was no different for me, early in my career, when I was that person. The one and only person who facilitated the release. I also didn’t want the team to pause releasing and making product improvements when I was away. Recognising this issue and wanting to claim some of my time back I devised a strategy to decentralise release planning through a release checklist.

The Release Checklist

The tool that I developed was a simple Release Checklist. Since then I’ve implemented this tool in over a dozen product teams who have faced similar challenges, in different companies around the world. Honestly, it’s nothing special and I think the best tools aren’t. They are deceivingly simple and when embraced and executed well they have exponential leverage.

The inspiration came from wanting to get everything that was in my (and others') heads down on paper. So the next time we did a release I got a pen and paper and we created a run sheet. Each step we took as a team, each thing that we checked or asked for we added to the list. This list eventually became a confluence page. This was our first attempt at decentralizing and removing the single point of dependency.

Our initial intention was to do just that, have it as a confluence page and when I was away the tech lead could reference it — but I decided to take it one step further. Wanting to further decentralize and encourage self-organization I decided to use the checklist for our next release.

In the lead up, I pulled the confluence page up at each daily standup. As a team we then worked through the checklist ticking items off. This is where the magic happened.

In the following release, I asked the team to pull up the checklist again and do exactly the same as what we did last time. However, rather than myself being the one who pulled the list up and facilitated the conversation, I had one of the Engineers do it.

This was the final move to decouple myself from playing release manager.

Over time we iterated on the checklist and it eventually became a comprehensive spreadsheet, where we could track each release and physically tick items off — like this:

`Example Release Checklist — redacted as it's a real example`

But no more was I needed to play the role. Each release we had different team members pull the checklist up. The team self-organised and ticked things off without being told to. All facilitated by the checklist.

Building your own Release Checklist

The way I started was to write down the activities we took during the next release. I found it easier to capture it whilst we were actually doing it, rather than trying to remember what I did last time.

Step 1: Write down all the activities that are taken and checked as part of performing a release

Step 2: Put this list into a spreadsheet. Leave the first tab as the blank checklist.

Step 3: Each time the team releases, duplicate the first tab and rename it to the release number.

Step 4: Do a retrospective on it at the end of each release and iterate on it.

Using the Release Checklist

Leading up to the release, the Release Checklist should become the centre of focus for the team.

I like to have someone pull up the checklist as part of sprint planning and we work from it. Step through the checklist and create sprint backlog based on what items are needed to be done for this release.

This encourages collaboration and also sets the tone that releasing is a team effort, not something engineering or a release manager does.

For example, sending communications to our customers would most likely be done by the Product Manager but checking for schema updates could be any engineer.

Another example is there may be digital assets that need to be created. For example, if you work on an app, you may need to update the graphics on the app store as part of the release. This could be something the designer owns.

It's important to not have the same person pulling up the checklist and ticking things off each release. It’s best that it is something that is either rotated or self-organized.

Tip: One thing I like to do is to make the checklist a google spreadsheet so that everyone can edit it. This way we’re not dependent on any one person to action items — anyone in the team should be able to check off items that they have completed. It’s also important to note that you don’t need to check-off everything in the list for every release.

For example, “communications out to customers” is a common checklist item. This doesn't need to be checked if there is nothing to communicate to them. For example, say we’re doing a server upgrade or something and there is no expected outage.

Release Checklist Template

Feel free to use my release checklist template here.

Release planning template — 🔗 here

One Final Thing

Whilst we’re on the topic of releases — a good practice to get into is setting goals for your releases — if you’re not already. In other words, strive to answer the following questions:

Who is the target market for this release?
What are we hoping to achieve by releasing?
What outcomes do we expect from this release?
How do we intend to track/measure whether it was successful or not?

And finally, make sure you have a contingency plan, not just a rollback plan. Spend time as a team brainstorming what might happen — if this A happens we will do B. A great tool to support this brainstorming is a post-mortem.