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.
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:
There are some deficiencies to it that I improved over time or would change in the future:
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:
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.