DEVELOPING AGILE ROADMAPS

10 min readJun 18, 2021

Dr. Jordan L. Fletcher, JUN 2021

A question that I have come across multiple times in the past year is “how do I create an effective roadmap for an agile software development effort?” Most roadmaps I have seen on traditional projects are developed once and then used as the basis for development of an integrated master schedule, which is the planning artifact that is regularly updated. As agile methodology embraces change and favors working products over documentation, the notion of a roadmap almost seems at odds with agile development. However, that is an incorrect assumption, as an agile roadmap provides a balance between:

a. The thrash of continuous updates and priority changes from not following a plan (leading to subverting the product vision or lack of progress toward end goals)

b. Investing heavily in up-front requirements definition, timelines, and plans such that a product team loses all flexibility to adjust priorities, schedules, and features based on user feedback, or new information resulting from development and discovery

I reviewed several articles that detail ways to approach a product roadmap in the abstract and summarized my findings below, followed by a hypothetical example.

Q: What elements should an agile roadmap contain?

A: Roadmaps should be tailored to the purpose and audience of the roadmap. The roadmap should contain enough generalized information about product development efforts and rough targets to assist with increment (e.g., sprint) planning and dependency planning / deconfliction, without committing development teams to exact feature sets or timelines which would limit discovery and flexibility. Reviewed articles provided a range of opinions on content:

Roadmaps may contain information about the product vision (e.g., goals).
Roadmaps may contain high level features and metrics related to the domain area (e.g., a web-based product may track when web content is made available to consumers, or when the site will be able to support a meaningful target number of visits per day).
Roadmaps may contain high level requirements that precede product backlog creation. In that case, the roadmap should contain requirements and timelines.
Roadmaps may contain initiatives (e.g., projects / sprints), so that product teams can synchronize efforts and stay informed.
Roadmaps may include dates or calendars (articles contained multiple contradicting opinions on how to represent timelines and milestones).
Cost information should rarely be included in a roadmap, but program budgets may impact product feature or schedule decisions, which may be depicted on the roadmap.
Roadmaps should not contain details such as epics or user stories, and that those should instead be included in the product backlog.

Q: How often should an agile roadmap be updated?

A: A roadmap for an agile software development effort should have updates triggered by changes to the market conditions / environment, and by changes to the product as effected by development or users. In the case of a nascent product in an emerging / dynamic / volatile market, the roadmap could change frequently — as often as every increment or sprint. In the case of an established product with a stable user base in a well-understood and static market / domain, the roadmap updates might be triggered annually as part of scheduled reviews or team retrospectives. The maturity of the market and product will impact the update frequency but will also likely affect the roadmap development activities and focus areas. For example, a product being built for a nascent market such as driverless technologies, may focus more on the vision for the product and the feature set, vs. focusing on hard-to-define elements such as market fit, distinctive metrics, and policy alignment. Similarly, a product roadmap in a nascent market may draw more from active research in a technology area (e.g., journals and conferences) vs. market studies.

Q: Who are the users / audience for a roadmap?

A: Multiple different stakeholders can benefit from a roadmap, but the derived value depends on the organization composition and the roadmap content. Understanding who your intended audience is and what you want them to get out of the roadmap can help focus roadmapping efforts. Some of the personas that may benefit from an agile roadmap include:

The Program Manager, who can use the roadmap to sequence staffing actions and procurement, synchronize product schedules across a portfolio, update stakeholders, or inform other program-level activities such as marketing and sales.
Product Owner(s) who can use the roadmap as the basis for development planning, feature prioritization, work estimation, or for communication and synchronization with other product owners.
Product Delivery Team (developers and IT operations personnel) who can use the roadmap to gain an understanding of the relationship of a sprint, epic, or feature set to the larger product vision, which can then help inform design decisions or tradeoffs.
Operators (users) who can use the roadmap to gain insight into major product feature roll-out or scheduled improvements, leading to more informed feedback on feature prioritization or training needs.

Q: How should a roadmap be visualized/formatted?

A: Nearly every article stated that roadmaps should be kept simple. A Gantt chart is more applicable to a short duration sprint schedule and/or backlog, as the coordination and effort to create a longer-term roadmap with information like dependencies and activity relationships will outweigh the benefits and ease of updating the roadmap. Some diagram types that may be applied to a roadmap include:

Swimlane, where initiatives are arranged in lanes corresponding to the products or goals, with a timeline at the top or bottom, proceeding from left to right. Relationships between initiatives (e.g., shared outcomes, feature sets, product line) are the primary organizing factor and time is overlaid with variable periodicity and duration. Other variations of the swimlane roadmap include matrices, calendar plots, and goal-oriented roadmaps. The graphic is a free downloadable template from officetimeline.com [5].

Fishbone, where initiatives and/or features are cascaded into, or branched out of a timeline in the center of the diagram that proceeds from left to right. Time is the organizing factor and relationships between initiatives (other than time sequence) are typically abstracted. Note there are several variations on this basic visualization using chevrons, circles, arrows, or other graphics (e.g., curved highways and signposts) or organizational techniques such as the now-next-later roadmap. The graphic is a downloadable template from slideteam.net [6].

Horseblankets where the procedural steps (i.e., initiatives) are laid out in succession with only a cursory notion of time. The “story” (user goals, sequential process, user experience) becomes the primary factor in this type of roadmap, and timelines and relationships between initiatives are abstracted. Some examples of horseblankets are journey maps [9] and story maps [15]. The graphic is a downloadable template from sampletemplates.com [7].

Q: What agile artifacts and tools support the creation/content of an agile roadmap?

A: The source artifacts are highly dependent on the intended audience, format, and purpose for the roadmap. However, tools used for product backlog maintenance and grooming are great candidates for automating the development / updates to the roadmap, as sharing these tools and the underlying data will improve consistency between the product backlog(s) and the roadmap. Some examples include:

Product backlog and associated DevOps management tools (e.g., Gitlab, Jira)
Product vision
Concepts of operation that may stem from policy, doctrine, or exercise / demonstration
High-level / thematic user stories or need statements
Context map [8]
Service blueprint [9]
Story map [15]
Walking skeleton [16]

Many of these key artifacts for an agile roadmap are generated during discrete agile design events, such as event storming and domain driven design [14], rather than being part of the “code writing” process of software development. Additionally, events such as conferences and trade shows may help set development context or provide diverse insights from sources external to a product delivery team.

EXAMPLE:

The roadmap concepts have a number of variables to be considered and the following section provides an example of how factors combine to create a valuable roadmap artifact. In this hypothetical scenario, a US Government program office is taking an agile DevSecOps approach [10] to software acquisition. The program manager has assigned multiple product teams and product owners to work on a portfolio of “command and control” software intended to modernize, improve, and replace legacy systems.

The product teams all follow agile, user-centered design practices, including a period of discovery and framing [17] to understand the market and trends. The teams are working with current system users to gain a better understanding of current conditions, using techniques such as event storming and domain driven design [14] to identify and prioritize pain points, and to set a vision for the portfolio’s products. The team has decomposed the problem domain, and created a strategy with prioritized objectives to develop the products and to groom their backlog, but soon found that:

Synchronizing feature development between product teams requires extensive coordination and effort
External stakeholders are confused about the production timelines and feature sets associated with each product
As new services and technologies in the “command and control” marketplace are discovered, product owners and developers are uncertain of how and when to best onramp or leverage the newly found capabilities
Budget issues and potential cuts to features and product teams result in hard-to-predict impacts on program-level objectives

In this example, there is an obvious need to create a roadmap to support the needs of the program manager, external users / stakeholders, product owner, and developers. The purpose of the roadmap is to synchronize product development across the portfolio, provide information about feature sets and timelines for production, plan incorporation of new capabilities found during discovery activities, and quickly forecast the program-level impacts from budget decisions.

While there exist multiple different roadmaps that could provide value to stakeholders, the team settles on the popular swimlane style of roadmap. The swimlanes correspond to products in the portfolio, and initiatives are organized around sprints. The organization around sprints enables dynamic mapping to the respective product’s backlog, which is linked to features, program-level objectives, and timelines that have been developed during agile development and design activities. The timeline is divided into quarters forecast over a 12-month period, which allow for enhanced dialogue between product teams who were trying to synchronize efforts. The current and next quarter activities are well-defined, with less detail in later quarters to allow for flexibility and discovery. To support immediate program-level association, the initiatives on the roadmap are color-coded based on supported objective. Minimum viable product (MVP), minimum viable capability release (MVCR) [18], and experiments are explicitly incorporated into the roadmap to ensure external stakeholders and users have an understanding of key milestones and decision points. The roadmap is thus a dynamically updated artifact that can be used to quickly understand the focus areas of each product and associated objectives, and to also quickly drill into specific feature sets due to the linked backlog.

The program manager, product teams, and other key stakeholders can then use this roadmap to iteratively balance program and business needs with what is technically possible. One key activity involves using the roadmap to color-code entities, value objects, and services in the program-level domain-driven design context map, based on notional timeframes for support / availability. This view of the design provides users and stakeholders with a better understanding of when product features and functions would be put into production, resulting in better forecasting of training requirements and product availability for system-level experimentation and demonstration. Additionally, the program manager is able to use the roadmap and product backlog together to support hard choices between products that have to be cut or feature sets that have to be delayed due to budget issues. Lastly, developers and product owners are able to use the modified context map to make informed decisions about feature prioritization, as well as which services and technologies they should incorporate to their product, and when those capabilities should be sequenced in.

References and Resources

DEVELOPING AGILE ROADMAPS

Written by Jordan Fletcher