Creating a roadmap can be a challenging task. I can't really say I am an expert on the matter, but have done it a couple of times. The most recent one, I put together a workshop that got fairly positive feedback and so I'm sharing it for the benefit of anyone interested.
This post describes a pragmatic approach to creating a roadmap for half a year, but can be extrapolated to cover whatever time period you need. Just be aware that the longest the period, the fuzziest it will be after the first 6 months, particularly in an agile environment with quarterly OKRs.
1. Plan out the session
I used a Miro board as the canvas for the workshop. Having a tool that allows for realtime remote collaboration is essential.
Lay out the different steps (which I cover below) and add a time estimate, so that everyone can check if each part is overrunning.
You don't need to cover absolutely everything in one session. Do it if you can, but this can be quite challenging, as there is a lot to cover, and probably people will be tired after max two hours.
A high level overview of the board we used looks like this:
2. Ice-breaker
It's usually a good idea to start with an ice-breaker that will get people in the right mood. During the workshop, everyone needs to be participative. Spending a few minutes at the beginning, having a laugh and chatting informally, will definitely be beneficial.
You can use classic exercises from your retrospectives, like guessing everyone's favourite food or describing your current mood with an emoji. The sky is the limit.
3. Set out expectations
It is worth spending 5-10 minutes clarifying the expectations for the workshop. What are we trying to achieve, what's in scope and what's not?
As the facilitator, come prepared with a proposal. Read through it during the meeting and get agreement or make amendments.
Some of the categories we covered last time were:
- What we should do if we had unlimited time
- What we are actually doing today
- What we are not doing today
- What we should follow up on
These are just examples, feel free to come up with your own version.
4. Build individual roadmaps
Here you will start the actual roadmapping exercise. It has a few steps.
4.1. List all the projects you can think of
In a column, list all the projects/epics in your area. Doesn't matter if they have been discussed previously or not, and you are encouraged to think out-of-the-box.
As a facilitator, it is a good idea to pre-populate the list with the projects you know of already. This will save time and will serve as an example for others to contribute.
Remember you are listing projects, not tasks nor programs.
Give people time to add projects to the list. You can use different techniques for this e.g. round robin, silent brainstorming, 1-2-4-all, free for all.
At the end of this stage, you will have an unestimated, unordered and unowned list of projects that contains everything everyone in the room knows about the work you need to do in your area.
4.2 Estimate using t-shirt sizes
Estimates are context dependent. What is big for one team, might be medium for another. Here, use whatever makes more sense to your team/area. For example, if you always work on one single thing at a time vs you usually parallelise two or three things, your estimates might differ. These are just ballpark figures, so don't worry too much.
The sizes we used were:
- Small = 1/3 of the quarter
- Medium = 2/3 of the quarter
- Large = 1 quater
- Extra large = more than 1 quarter
In Miro, it is easy to resize rectangles (projects) to match the reference sizes at the top of the list (see the template).
Go through the projects from the top and estimate all of them. On a second pass, try to break down the biggest ones into smaller chunks.
4.3 Order projects using a naive approach
A simple bubble-sort will do. Starting from the top decide wether the next project should be done before or after the previous one. Very quickly we started moving things up or down, and ended up with a reasonably well sorted list. Doesn't have to be perfect, but it should help to group things that need to be done roughly at the same time, and identify things that can probably wait.
4.4 Roughly define which team should own each project
If you are building a roadmap for more than one team, at this point is useful to colour-code the projects to highlight which team will be the official owner of the project. In practice, this means the team that will provide an Epic Owner for the project. If you are unfamiliar with the concept of Epic Owner, it's the person in charge of an epic acting like the project manager (plus other things, but that's a topic for a different time).
Sometimes ownership is shared, and sometimes you just don't know. This is absolutely fine at this point, especially for things that will happen 2+ quarters away from now.
4.5 Build roadmaps individually
Give people 10-15 minutes to build their own roadmaps with the projects on the list. The goal is to prioritise and parallelise things. Think about dependencies and respect the order as much as possible. But don't feel constrained by the order that came out of 4.3. It was ordered naively after all.
5. Build a straw-man roadmap together
At this point, everyone should be pretty familiar with the items in the roadmap, the non-controversial topics, and the trickiest ones.
As a group, try to put together a final version. Use arrows to explicitly flag dependencies between projects.
It's very important to remember that this is just a straw-man roadmap, meaning it's an advanced draft. Not something to be publicly shared, as it needs more work still. But a helpful internal tool nonetheless.
The output will be useful in deciding what to do next, and for OKR planning. But things can, and most certainly will, change.
6. Reconcile with OKRs
Let's think for a minute about what we have. We have a list of things that we want to build as an area (area meaning the part of the business you are roadmapping for, made out of a subset of the total of teams in the organisation). We know how those different things relate to each other in terms of dependencies. And we roughly know who is best placed to own each of the work streams.
The are two missing pieces still.
Strategy
Ideally you should write your strategy briefs first. We had some drafts, but we made a conscious decision to invert the order. Our aim was to gain clarity about the future and prepare ourselves for the imminent OKR planning.
If you have already written a formal strategy, for the most part, your projects will come directly from it.
OKRs
Company-driven goals might clash somehow with your roadmap. You wouldn't know until close to the beginning of next quarter, when company OKRs are refreshed (this might be different in your case, depending on the cadence of your organisation).
Even though adjustments might be necessary, company OKRs don't invalidate your roadmap, but you might want to reserve certain capacity to make sure you can accommodate unexpected needs. Typically this will be in the form of OKRs that require enabling others to deliver their goals, or to contribute to pushing metrics in reaction to a market change (like during COVID).
Having a roadmap will prepare you better with the tools you need to accomplish company OKRs. It'll be much easier to find something in your roadmap that supports one of those company goals, than having to come up with an entirely new project on the spot. So you are increasing the chances of having something ready, that is aligned with both the company goals and your long term vision for your area.
7. Share with the teams and keep iterating
It's important to get buy-in from the team that will actually work on the projects. You want to give everyone a chance to contribute and provide input if they have anything to add. Share your roadmap, ask for feedback, learn and iterate. Do that a few times and you will have a solid and always up-to-date roadmap, ready for any planning cycle.
Top comments (0)