A roadmap provides a visual statement of where we are taking a product and a backlog gets us there

Agile development spends a considerable effort on defining a backlog, but spends little time on roadmaps. This can give the impression that a roadmap is outside of the agile software development lifecycle. But that’s far from reality. A good roadmap sets the vision of a product and a backlog is the actionable expression of work for a team to undertake to achieve the vision.

In the ideal flow, a roadmap is created, the backlog is populated, development starts, and features are delivered. The each step builds upon the previous step. In the flow of work, we rely on work to be broken down, taking the roadmap and building out a backlog.

Building a roadmap and building a backlog require two different sets of skills and more importantly, different decisions to be made. A roadmap is typically crafted in conjunction with stakeholders and product/engineering leadership. It requires an understanding of the market the product and business operates within and deciding what opportunities to pursue. Most roadmaps also include a sense or indication of time, and thus require an estimate on effort, either well informed by consulting the engineering teams by analyzing the ask and crafting an estimate based on the understanding. Or, lacking the time or effort, a random guess is applied and the roadmap is adjusted later.

Building a backlog, by contrast, requires understanding the problem to be solved and enough details of the solution to sequence work and identify dependencies. It’s a collaboration between product and engineering, requiring both parties to contribute, on one side the problem and the constraints around the potential solution, and on the other side a solution that is actionable and solves the given problem.

Product team members are more heavily involved in upfront activities and transition the knowledge and activities to the engineering team members. Roadmapping is largely a product activity with some engineering consultation. Crafting the backlog is a joint exercise between product and engineering. Development then is a largely engineering effort with some product consultation. Release and support is largely an engineering function with some product consultation as needed.

Delivery can happen without a roadmap, but it cannot happen without a backlog. Without the collaboration between product and engineering to explore problems and craft solutions, the development team cannot plan yet alone build a solution for the business or customer.

That’s not to say that a roadmap is completely useless. A roadmap sets the vision for where we are taking a product. This gives the development teams a sense of purpose and direction. It also aids in the solutioning of current work, giving an indication of how the teams may have to evolve the system in the future.

The key audience for a Roadmap however is the stakeholders. Stakeholders responsible for budgeting decisions. Stakeholders who set organicational direction. Stakeholders who must make marketing plans, training documents, and staffing decisions. A roadmap is a sales pitch and a communication device, meant largely for the broader organization to consume. In many cases, its necessary to receive funding or justify continued investment in a product.

Roadmaps and backlogs are intricately linked. A roadmap sets the visuion while a backlog organizes the desired roadmap into an executable plan. While it’s rare that a backlog could exist without a roadmap, a roadmap cannot be realised without a backlog. Both are necessary for a well-functioning and evolving product.