#toolhacking for fun and ITSM – Release Planning with Trello

I love Trello. For those unfamiliar, Trello is a SaaS kanban board / taskboard. It’s free (mostly) and is virtually idiot-proof to set up and start using.

You don’t have to adopt the kanban methodology to use a kanban board, Trello works just as well as a visual task board, the tasks moving from left to right across columns as they progress, and the columns representing the states of the task (eg. ready, doing, done).

Here’s a quick example:

Introduction Before
Introduction After


Task Agility

Agile teams should be very familiar with kanban boards (as well as the kanban method) and will probably already be doing some kind of release planning, so this article isn’t really for them.

The agility I have in mind is the one that lets you quickly reassign an object from one group to another, for example a release scoping candidate from one release to the next.


Use case 1 – Lots of components, lots of regular windows, lots of movement, fast cycle time

Imagine being a release manager on a busy project delivering several systems, perhaps in a Service-Oriented Architecture with no (or infrequent) functional dependency between the systems and individual development/test teams each building at different paces.

Imagine you’ve agreed 1 release window a day with your testers and other stakeholders, and you also have to factor in maintenance slots, data refreshes and the delivery of new hardware to keep up (because performance testing is optional, said no release manager, ever…)

Your Trello task board may end up looking something like this:

Release Scoping Planner
Example release scoping board

In the above example, I’ve defined a column on the left to store potential component release candidates not yet allocated to a release, and the next 3 days worth of releases have a column each. I’ve used some inbuilt labelling functionality that comes with Trello to show red/amber/green flags for each candidate – something I use to tell me how likely the candidate is to make the cutoff for that days release or how downright invasive it is.

I usually keep it this simple if I’m in this kind of situation. Simple means fast and fewer chances of mistakes. The features and bugs in each component will be held somewhere else, all I need to know is which bit of code is going on which day and what else is happening.


Use case 2 – Tracking the status of several slower releases

Now step back from rapid releases and think about the releases where you’re still running several at the same time, but each release takes time to build and package and get all the documentation and training done, maybe you have some 2-3 day auto test packs to run on it as well.

Using a kanban board here lets you visually track the status of each release, like this:

Release Status Tracker Simple.png
Simple Release Status Tracker

In this example, I have some monthly releases in progress as well as a quarterly patching job. I’ve used RAG status labels to show risk of each release, and you’ll also notice I’m showing a date on each (using the Trello ‘due date’ feature) to let me see the deployment date of each release at a glance.

Additionally, Trello support templated checklists. So if you want to build a release checklist for simple releases up to full service releases with operational acceptance and service introduction type activities, you can do this too:

Example Checklist



Visual taskboards like are a useful alternative to spreadsheets or gantt charts. They’re great at presenting information simply and allowing you to be flexible and agile in your planning.

I use Trello a lot (both free and premium versions) as it’s so simple and fast to use. There are alternatives with some richer features which I may cover in a future article, but if you’re struggling in scenarios similar to the ones above, it may be worth giving Trello a try.