Be more efficient and deliver what customers really want — that is the promise of adopting an agile development approach. Agile’s iterative, incremental methodology appeals to organizations that want to deliver value quickly to customers. Companies practicing agile want to gain valuable customer feedback with each iteration. Then they integrate that feedback into their agile product roadmaps to build better products.
So how do product managers build an agile roadmap to support agile development? The first step is to understand the purpose of an agile roadmap, and how it is different from a product roadmap developed by an organization using more traditional waterfall development methods.
A waterfall product roadmap communicates a long-term commitment to building specific features on a set timeline. However, an agile roadmap accommodates inevitable changes while still committing to getting meaningful work done. It communicates a short-term plan for achieving product goals, with the flexibility to adjust that plan according to customer value.
Here are some key ways that agile and waterfall roadmaps differ:
|Waterfall roadmap||Agile roadmap|
|Planning horizon||Years||Months or quarters|
|Resource / capacity planning||By major project||By small team|
Now that you know how an agile roadmap is different from a waterfall roadmap, you are ready to build one. Here are seven steps to building an agile roadmap.
Initiatives (also called epics by some teams) define the broad strategic themes for the work that will help you achieve your goals. Initiatives are broken down into features and user stories, often spanning multiple releases.
Defining strategic initiatives defines the high-level work that is necessary to accomplish the goals. They help you clearly communicate the roadmap strategy to stakeholders without having to get into all the details. If your team does need to change course, you should start by reevaluating and changing (if necessary) the strategic initiatives before defining new features to work on.
Building agile roadmaps requires frequent communication and collaboration between business and development groups, and between the organization and its customers. For example, it is critical for you to build the roadmap with development input, so that realistic estimations of value and effort result in a feasible plan. In addition, an agile roadmap requires harnessing the effort of all the departments — design, testing, marketing, and sales — whose work is crucial for planning and delivering a Complete Product Experience.
Many agile practitioners also find they need to work with traditionally non-agile groups — such as budget offices and the legal team — that require longer timelines. In this case, an agile roadmap can be especially helpful in collaborating on parallel, multiple work streams.
The product vision, goals, and initiatives defined for an agile roadmap give product managers a prioritization guide for decomposing large themes of work into features. Development teams can then break down features into technical requirements, estimate scope, and help organize them into sprints. The result is a backlog of features and user stories — with a clear connection to product strategy — on which teams can quickly execute.
You can steer the agile roadmap by frequently assessing their strategy — if the goals change, the work that is prioritized should change too. But frequent change raises the risk that goals may shift prematurely. Mapping the work against a clear product vision can show you where your team needs to make adjustments (versus where you should stick to the plan).
An agile release delivers an increment of product value to customers in a defined timebox. It differs from a sprint or iteration in that it delivers a new customer experience (rather than just shipping code) and encompasses cross-functional work (like QA, marketing, and sales training). As a product manager, you are responsible for helping to optimize the entire new customer experience. A release also reflects important milestones — such as a market launch or architecture upgrades — and shares visibility into dependencies across the work and teams.
Releases represent all the touchpoints where customers will interact with a new product experience and are defined by the cross-functional work necessary to deliver this experience. The releases on an agile roadmap communicate to customers approximately what they should expect to see and when.
Customer delight is a core tenet of agile approaches. Gauging whether customers are happy requires collecting their feedback. And that can be done via user experience interviews, ideas portal submissions, usability testing, and usage data.
After you have collected customer ideas for improving the product, they need to score and prioritize those ideas for a future release backlog. Customer ideas — along with the product’s vision and goals — should drive prioritization of what to build next.
If you are building and executing on an agile roadmap, the following questions will help you pave the way:
With clear strategy, frequent releases, fast feedback, and adaptive prioritization, an agile roadmap can help organizations deliver customer value — faster — with reduced risk and waste.