Backlog and roadmap

In Process, I discuss workflows and how they impact the everyday life and productivity of teams. Here I focus on the tooling we use to operate our workflows: backlogs and roadmaps. Although these tools depend on the workflow of choice, it's easy to forget that, at their core, they're communication tools. As we may forget that, we often try to change our workflows instead of focusing on the efficiency of our communication.

First of all, let me say how I define these terms:

• Backlog

  I think of a backlog as a written list of short-term tactical goals. It structures, organises, and visualises the tactical aspects of your strategy. Its main function is to answer the question "What are we going to do soon?". "How soon" depends on your workflow and it's out of the scope of this conversation.

• Roadmap

  Roadmap's main function is to answer the question "Where are we going as a team?" It communicates a vision and a purpose. It gives teams the opportunity to take everyday decisions without forgetting the big picture.

These tools are shared and discussed within the product management group. Every company interprets the product manager role in a different way, and that has implications on how the day-to-day relationship between a product manager and their development team works. The shared nature of these tools is exactly what makes them so relevant from a communication standpoint. The better these tools work, the more productive the entire organisation is going to be.

As backlogs and roadmaps answer different questions, I discuss them separately. Let's start with roadmaps.

A roadmap is a physical or digital representation of a team's mission. Each team has a mission and the roadmap represents its execution. What's relevant to the communication infrastructure of your organisation is the feedback loops a roadmap enables. Two loops are particularly important:

• If developers have a good understanding of the big picture, they can take more thoughtful decisions about the system they're building. Every technical decision is a trade-off between what works now and what needs to work tomorrow. The more developers know about what's coming, the clearer the distinction between now and the future becomes. You know this is working when you can hear developers say something like "We're going to do it this way because X is coming up. There is no point in doing Y either".

• Often developers don't really know what happens to the features they ship. A good roadmap must provide a mechanism to close the gap between shipping a feature and rolling it out to customers. For example, you could batch all the recently shipped features in a section of the roadmap called "To verify". These features stay there until you verify that they worked out. This benefits both developers and product managers. Developers know why they built a feature and how customers use it. Product managers are held accountable for their decisions and can celebrate their success.

Backlogs are trickier because they're on the edge of two different functions. A feature in the backlog represents an output for product managers and an input for developers. This duality has some implications.

Product managers consider backlogs a means to an end: they put stories in a backlog because that's how one builds a product. I sometimes joke that a backlog is just an organised wish-list.

On the other hand, developers consider their backlog as a series of requests for change to the system they're responsible for. So they spend time looking for things like inconsistency and feasibility. This often leads to unproductive communication. It can make people feel they aren't working towards the same goal.

Designing a good backlog is hard because of its duality: it represents an output for some team members and an input for others. I ask developers and product managers to find the simplest approach that works for both parties. The way I guide them in this process is by helping them focus on the backlog as a communication tool: it's how product managers say "This is what we're working on short term". It's not a place for transactional work; it's a place for a high-level collaboration between two parties that have one goal: shipping awesome work.

Teams are always different from each other, so good backlogs should reflect that. Depending on the team, some aspects are going to be more important than others. Trying to standardise how backlogs look across teams is doomed to fail. I've made this mistake myself more than once.

It's best to focus on what makes a backlog an effective communication channel. First of all, features in a backlog have to be work-ready. It may seem obvious because the goal of the backlog is to organise the short-term tactical goals of a team. But I've seen the backlog being used as a forum for discussion far too many times.

A backlog needs to be as small as it can be, but not smaller. Once again, the idea is to communicate what's coming shortly. There is no point in populating the backlog with things that you aren't going to build in the immediate future.

Different teams may put different kinds of tasks in their backlogs. I've seen teams that use backlogs only for features and bugs, while other teams also create tickets for data migration, reports, system maintenance. The key is that team members agree on what goes in their backlog and have an good way to visualise task types. The backlog shouldn't lead to more questions, it needs to clearly answer the question "What's coming up next?".