The theory behind effective long-term planning for software products is a fascinating topic. But sometimes, it makes sense to get more practical. The problem with practical examples is that there is no one-size-fits-all solution. Companies and teams have their own needs and habits. But there is an ideal solution that we can aspire to, even if we don’t get there 100%.
We need a flexible method that applies to most software teams, whether they use Scrum, Kanban, or some custom process. It must allow us to make long-term promises while still being feedback-driven. More agile product development, less projection-based project management.
This is what an example of such an ideal plan looks like:
Roadmap
Let’s start with the most high-level component. The roadmap is the company-wide long-term plan. There is one single roadmap that unifies the different team plans. We plan “focus blocks” at this level to address a single problem rather than thinking about features.
Classic plans typically contain a list of features and struggle to fit them all in a timeframe. Focus blocks turn this around. They ask, “what are the most valuable solutions to the problem we can build in the allotted timebox?” They improve productivity by removing context switching.
We also plan the team’s recovery time to innovate and repay technical debt. One or two weeks between focus blocks is a good rule of thumb.
While Now/Next/Later style roadmaps are popular these days, I recommend mapping on a timeline instead. Stakeholders want to know when they can expect something. The roadmap should reflect that. Unmanaged expectations spell disaster.
Backlog
On the team level, there’s the backlog, and each team should have exactly one. It’s the best-known and most abused planning tool in the history of software development. Backlogs are a team’s tool for short-term planning.
The roadmap contains a timeline with problems, and at the start of every focus block, the team selects ways to address the current one. These stories are added to the backlog and prioritized by value. The team will unlikely complete all of them during the timebox, so we’ll do the most valuable ones first. All unfinished tickets get deleted at the end of the timebox. The goal is to address the problem gradually, not to build all features we can imagine.
The backlog is ideally empty at the start of the focus block, but a few sources of “unplanned work” feed into it.
Unplanned work
We spend too much time thinking about new features when we talk about the yearly roadmap. Road mapping sessions often create a wishlist rather than a realistic plan starting from the team’s capacity. We consistently underestimate the need for maintenance and operations.
The recovery timeboxes help us tackle predictable maintenance, but the truth is that unplanned work will happen. Unforeseen events will knock on the door and mess up our delicate plan. Unexpected work items should be limited to bugs, customer support, and incident management. These tickets belong in the backlog as we want to fix them in the short term rather than save them up for later.
The recovery timebox is excellent for handling these tickets, but managing unplanned work can sometimes cut into the focus timebox. That’s OK. Our aim is a reliable plan, so if we are churning out low-quality features, this becomes a natural brake forcing us to slow down.
Idea Incubator
Finally, there’s the incubator. That’s where we capture and flesh out ideas we might want to build. Here we describe the problems and collaborate to design solutions. This should be in something other than a ticket-based system like Jira or Azure DevOps. Coming up with ideas is trivial, so we want to increase the friction for idea people. Throwing a one-liner in a Jira ticket is just too easy. Ideas should be valuable enough to spend some time writing an article in Notion or Confluence.
The idea incubator becomes a living document describing the product’s solutions, the problems they try to solve, and the decisions made to get there.
These components work together to form The Plan. It allows us to plan long-term for multiple teams and keep our promises by focusing on problems rather than features. It gives our teams the tools to work on the next most valuable thing while carving out time to pay back technical debt and innovate. It puts developers in the position of problem-solvers and takes away most context-switching by focusing on a single problem. Finally, it allows us to handle bugs and customer support in a timely fashion.
Organizations can’t adopt this kind of planning overnight. While it can plug into most software delivery processes, it often requires organizational changes and increased team maturity. But if you’re making your annual roadmap and notice that it looks too good to be true, give this Planned Attention format a try.