The ultimate guide to planning your roadmap and maintaining your backlog
What is this about
Managing product development is hard. There are many actors to satisfy, and many different levels of abstraction to maintain.
In this blog post, I will detail my experience of managing roadmaps. I will talk about the high-level and low levels, giving as much context as possible.
This blog post is intended for anyone working on a mature product. If you are still looking for your product/market fit, you may want to skip the QBOs section.
Being a product owner is all about managing expectations. Your business stakeholders are interested in the big picture, while your developers want to know both high-level and low level plans. It is important to manage the expectations of both groups. Your superiors meanwhile, will want a high-level view of 4 to 5 items per quarter.
Managing all these different views requires a bit of organisation. To make this happen, I maintain 3 levels of plans: the roadmap, the QBOs, and the backlog(s). We go into details on each below.
The roadmap is the highest level view of your plans. It should answer the question “What is the vision for your product“. A typical item in the roadmap should ideally take your team a month or two to develop. The roadmap should contain enough work for the next year, sometimes as much as two or even three years ahead. If you have more work planned than your team can deliver in two years, you have two options: begging for more team members or pruning the roadmap.
Here is an example of a roadmap.
You might notice that this is a simple roadmap, there are no timelines or complex relations. I know! And that’s on purpose.
Let’s be honest software development. As an agile team, your environment can change, your requirements can change, your team can change, business priorities can change etc. Putting times on a roadmap will achieve only two things: disappoint stakeholders and make developers miserable due to constant pressure.
How long would it take for a family of 5 with 2 children under the age of 10 to walk from France to China? Well I’d pay a beer to whoever gets that right. In my previous company, we fought hard with our business stakeholders to stop providing timelines. If you are reading this post, I encourage you to take on the battle, it is worth it.
Typically, you should review the roadmap with business at least once a month and update it accordingly.
Make sure you keep records of past roadmaps and update it monthly. It will become handy the day your stakeholders asked you why such and such features still have not been developed. Chances are that your stakeholders changed the priorities along the way but fail to remember it.
Quarterly Business Objectives (QBOs).
In a more mature company, you should try to establish QBOs Every 3 months to give visibility about the future to the business and to your team. Discussions go on between business with regards to prioritisation, and developers, with regards to implementation.
Typically, if your roadmap is up to date, you pick a few of the top items. This is a useful exercise to focus the team for the next 3 months, and to ensure that your stakeholders are aligned, as well as dependencies you may have with other teams.
How much work should I put in my QBOs?
QBOs need to be achievable, yet ambitious. Typically, you might fail 1 QBO per quarter and that’s ok. If you never fail, then you lack ambition.
What if my priorities change?
That’s OK, this can happen. While QBOs should help guide you, you are not bound to them, business priorities do change as things come up.
This is how your QBOs may look like
Keep them small. I mean, very small. This is critical as it will save you time when you review it. Every now and then, you will drag things into it as your QBOs progress or your priorities change.
People were telling me this for a very long time but I always found it hard to have less than say 50 items in a backlog.
You may tempted to add more things, but remember that you have a roadmap for a reason.
I find it is useful to separate the backlog into several parts to make it more manageable. Below I describe how we achieve this.
This is the obvious one. When you have agreed with your team what will go into the sprint, you create your sprint in JIRA.
Backlog (Product backlog)
This backlog contains bugs, stories and tasks to be worked on in the very near future. If it will not be achieved by the end of the quarter, do yourself a favour, move it to the low-priority backlog or put it back into the roadmap. All major and critical items fall in here. As you can see, we currently have 30 items in the backlog and we mark which ones are QBOs.
We maintain a technical backlog, which contains both technical tasks and technical debt. This is entirely owned by the development team and they decide on prioritisation. Every sprint, we will use some of those items and drag it into the Sprint (20% of the sprint roughly).
We have set it up as a “sprint” as far as JIRA is concerned as this makes the manipulation much easier: we can just drag&drop into the next sprint easily.
Finally, we also maintain a “pre-sprint” backlog where we put the likely candidate stories for the next sprint. This allows everyone to be aligned on priorities and we can start refining stories in the current sprint.