Agile roadmaps: build, share, use, evolve

Summary: A product roadmap is a plan of action for how a product or solution will evolve over time. Product teams use roadmaps to outline future product functionality and when new features will be released. When used in agile development, a roadmap provides crucial context for the team's everyday work and should be responsive to shifts in the competitive landscape. 

The idea that agile development discards long-term planning may be the biggest myth since the Loch Ness Monster. A roadmap is every bit as important to an agile team as it is to a waterfall team because it provides context around the team's everyday work, long term vision, and responds to shifts in the competitive landscape. But unlike a certain legendary Scottish water beast, an agile roadmap done right is easy to find and easy to understand. 

A product roadmap is a plan of action for how a product or solution will evolve over time. Product teams use roadmaps to outline future product functionality and when new features will be released. When used in agile development, a roadmap provides crucial context for the team's everyday work, future vision, and should be responsive to shifts in the competitive landscape. Multiple agile teams may share a single product roadmap, or each team may have their own product roadmap.

To build a roadmap, product teams take into account market trajectories, company goals, customer feedback and insights, and engineering constraints. Once these factors are reasonably well-understood, they are expressed in a roadmap as initiatives and timelines. Below is a very simple roadmap for a product team. Generally speaking, it’s best for product roadmaps to stick to bigger chunks of time like months or quarters, rather than committing to specific dates. To keep prioritization conversations focused on goals and strategy, instead of timelines, you can even try mapping initiatives to Now, Next, and Later.

Once a roadmap is built, it needs to be shared with the entire product team, leadership, and delivery teams so everyone understands the vision and direction. In many organizations, product owners create their roadmaps in PowerPoint and spreadsheets, and then email the slides and spreadsheets out to the team. While well-intentioned, this strategy is flawed from the start. Each team member has their own copy of the roadmap, meaning keeping everyone up to speed if the roadmap changes is both time-consuming and cumbersome (to say the least).

So how can product teams keep the organization better informed? Simple.

Most collaboration tools will automatically notify all participants of a project letting them know the roadmap has changed.

When adding an initiative to the roadmap, consider the following questions:

Before we talk about dynamic forecasting solutions, let's talk about the steps to build a long-term agile plan using the metaphor of building a house:

• What are the relative priorities of each initiative?
  • What impact will each initiative have on product and company goals?
  • How much effort is required for each initiative?
  • Are there enough insights and data to support pursuing an initiative?
• When do we intend to work on each initiative?
  • Are there particular dates the team needs to hit?
  • What dependencies does the program have–either internal, or on other teams
• Which teams are working on each initiative?
  • Do the current teams have availability in their schedules and enough capacity?
  • Can we keep the current agile teams stable?
    • If not...
      • How will teams be re-organized?
        • Are we accounting for ramping-up newly-formed teams in the project's timeline?

It's important to link your team's delivery work back to the product roadmap so you get that whole "context" thing mentioned above. A tried-and-true way of doing this is to map out the product ideas you’ve prioritized on your product map, then break those ideas down into epics, requirements, and user stories on your delivery roadmap. In most cases, each idea will have a corresponding epic that needs to be broken down into smaller tasks to complete. Connecting ideas on your product roadmap with epics on your delivery roadmap gives engineers context behind prioritized initiatives, like user feedback and research, at their finger tips. Plus, it makes it easier for product and development teams to make near-term decisions together that don’t compromise future work.

Say, for instance, that we roll out an extensive user profile feature on our website. If we find that our customers don't engage with the feature, should we continue to invest in it? Maybe, maybe not. We need to understand why engagement is low before we make this decision. So instead of pressing forward, we might opt to implement some A/B tests in the hopes of gaining some insight on the low engagement rate–which may point us in a direction that would have been far more difficult (or impossible) had we simply plowed ahead adding more bells n' whistles.

The ability to take a step back and research before you make a pivotal decision is the essence of an agile roadmap. And ideally, the discovery process of gathering insights and data is the first step you take before deciding to implement any decision. It gives the team the ability to evolve features as they learn more about a product, and the market.

Waterfall projects require a huge upfront investment. As a result, team members become emotionally attached to the roadmap and sacrifice making the right decision because it's too painful to undo the work they have done–a "human" sin, if ever there was one.

For it's part, agile development runs into three different risks:

• The team may lose confidence in the ability of the leadership to make strategic decisions if the roadmap is updated too frequently.
• The product might arrive too late on the market and miss out on pent-up demand if the roadmap is not updated frequently enough.
• Long-term efforts can seem "too big and too difficult" for shorter iterations. The team over-compensates by breaking the work down into powder-fine granularity, and ends up focusing too heavily on short-term results.

To combat "thrashing", staleness, and nearsightedness, keep the roadmap evenly focused on short-term tactics and strategic, long-term goals. A great way to do this is to review roadmaps quarterly, adjust as needed, and share. This works well in any size organization, but remember: a single roadmap can span multiple agile teams, so inspect, adapt, and communicate accordingly.

Keep reading The Agile Coach to learn about special considerations for larger teams who manage agile portfolios which have roadmaps across several teams. You can also try building your own roadmap for free in Jira Product Discovery, made for product teams.