Radarban Roadmap

As most of these posts have, I’ll start this one with “I’m really not that fond of roadmaps” — I tend to find them very restrictive.

The roadmaps I’ve seen before have tended to be linear, and have dates. This is the entire point in a roadmap for some people, but for me it is too restrictive if I am meant to be able to respond to changes and new priorities. Once you have a linear roadmap, people expect it to be followed and for things to turn up in exactly that order. This is even worse if there are dates on it, because they expect those things at exactly those times. (Again, this is probably why some people like them, but it doesn’t work if you are responding to what you are learning).

For me, a roadmap is useful for a couple of things. One is supporting a conversation with stakeholders around priorities and for managing expectations. If I am to manage their expectations, putting exact dates on things a long time away is not the way to do it. For prioritisation, I’ve written previously about how I don’t find it useful to prioritise more than the next few items against each other — beyond these you can just group up priorities.

Roadmaps are also useful to support team communications. Having a shared idea of what is and isn’t in scope, somewhere to store features we have an idea about but haven’t yet elaborated into cards (and shouldn’t spend time on quite yet), something to support a conversation on the scope of current features, and what might need to be done ahead of certain tests and releases. None of this requires a linear roadmap, or dates.

When putting together my current roadmap, I had in mind the radarban board that Paul D'Ambra showed at the Deliver Sessions last year. I liked that it allowed multiple items to share a space in time, and it constrained how many items would be the current top priority. It allowed for items to be prioritised against each other, and for things that wouldn’t happen for a while to have broadly the same priority so you didn’t have to worry too much about how they were positioned relative to each other.

Early roadmap for my current project using now/next/later to organise priorities

This was a very early version of my roadmap, which was trying to get all the bits and pieces that people were discussing visible, and sorted according to priority for delivery. It supported several things:

• Several items were removed from it as people pointed out they were out of scope for the current work — it made these differences in what people thought were in and out of scope visible so we could discuss them

• Several items were removed because of dependencies they had on other work going on —we will reintroduce them once they are possible

• Items were moved about as we learned more talking to our users and our stakeholders

• Items were moved as we decided on what the minimum set of features could be for a small release

• By having a WIP limit (defined by the available space), conversations with stakeholders around the prioritisation of work and not everything being top priority were a bit easier

There are some deficiencies to it that I improved over time or would change in the future:

• Some of the names are shorthand that the team understood, like “productionise core alpha features” — we knew what these were, but it isn’t a very clear block of work. I could have done with breaking that down a bit more to help communicate it outside the team.

• I could have done with splitting some of the features into basic functionality of the feature we would do now/next, and extra functionality of those features that would be for later — this would have helped the team more with understanding what the work in now/next covered, and manage stakeholder expectations

Later on in the project, we are starting to get nearer to the point where we decide what will be available for various users as we roll it out, and what we won’t do. I have been asked for more clarity on timelines, so despite my earlier reticence have added some indication of time. Now is the right time to do that, but I stand by not having it early on in delivery when timelines were unknown. This is the latest version:

Later version of the roadmap with more indication of timelines

As you can see, this supports stakeholders in understanding what features their user groups will have depending on when they come on board, and gives an idea of where we’ve identified further user research is needed into needs.

I’m sure it will continue to evolve, but I’m fairly happy with the radarban template as one way of roadmapping.