Effective Agile Roadmap Management: A Practical Approach

In the age of business agility, it is evident that many organizations excel in sprint-level planning and execution. However, when it comes to long-term planning, there often exists a significant amount of confusion regarding its application.

Frequently, organizational leaders are well-educated in Scrum, but their knowledge of scaled-up frameworks like DAD, LeSS, SAFe, and Nexus is often limited. A simple observation of the people in your workplace may reveal that most are familiar with Scrum but lack a comprehensive understanding of the long-term planning approach within the agile context.

When individuals are uncertain about what long-term agile planning entails, they tend to revert to what they know, often relying on Gantt-based planning. Read here to understand why this might not be the best approach.

In this article, we present an uncomplicated and effective approach to roadmap management, and we will illustrate how to implement it practically using Jira as the underlying tool. We will use a quarter of a year as an example for long-term planning and address planning, monitoring, and decision-making aspects.

Granularity of Long-Term Planning

Our initial step involves determining the building blocks for long-term planning. Planning at the story level can be too fine-grained for long-term purposes. For instance, when planning a quarter with multiple teams, managing hundreds of individual items can be impractical. To streamline the process, we recommend planning at the epic level, a step higher in the Jira hierarchy than stories (Epic-Story-SubTask). With this approach, planning a quarter’s work for five teams might involve as few as 20 epics, which is much more manageable.

Workflow for Long-Term Planning

The workflow for epics in long-term planning differs from that of stories. While stories primarily focus on execution stages in Scrum (To-Do, Doing, Done), epics involve several stages before and after execution. I suggest a basic workflow for epics, including the following steps:

• Discovering: The initial state with basic requirement details.
• Analyzing: Discussions between product management and technology teams on feasibility and high-level estimation.
• Slicing & Estimating: Breaking the epic into stories and estimating each story.
• Ready for Implementation: the epic is sliced into stories, all stories are estimated, and the epic is ready for implementation.
• Implementing: Stories within the epic are pulled into sprints.
• Deployed: All stories have been deployed.

While most of these workflow statuses are self-explanatory, we will delve into the importance of “slicing & estimating” and “ready for implementation” in the monitoring section. Please note that I have just listed the basic ones. You can add more as needed (e.g. Epic Rollout).

Placing Epics on a Kanban Board

For managing long-term plans, a Kanban board with epics is the preferred approach. Each column on the board represents a workflow step, as described previously. To plan for quarters, use swim lanes on the Kanban board to organize work into different timeframes. In Jira, the FixVersion field of an epic can be utilized to assign a quarter value (e.g., 2023-Q4). This setup provides a visual representation of the content for each quarter, the status of each epic, and helps establish priorities.

Epic Duration

An essential aspect is ensuring that epics have a well-defined timebox. To effectively prioritize, execute, and monitor work within a timeframe (sprint or quarter), a content-related item should be smaller than half of that timeframe. For sprint planning, stories’ duration and tasks should be smaller than half a sprint’s duration. Similarly, for long-term planning, epics’ duration should be smaller than half a quarter’s duration.

Determining the duration (cycle-time) limit of a story within a sprint is relatively straightforward. In terms of time effort, you simply divide the sprint’s duration by 2. When using story points, you select a story point value where an individual typically completes two stories of that size within a single sprint.

On the other hand, assessing the duration (cycle-time) limit of an Epic is a bit more complex. Epics often involve the collaboration of multiple individuals and, at times, multiple teams. To determine its duration intuitively, consider how many sprints it might take to complete the Epic based on its estimated effort and the teams allocated to the task. Aim for a number of sprints roughly equivalent to half a quarter.

Epic Size Estimation

Estimating epics is crucial for setting priorities and planning. Three primary methods are recommended:

• Rough estimation: Assign a size using a scale of numbers (e.g., 5, 10, 20, 40, 80). This is typically done during the analyzing phase and carries a confidence level of 20%-50%.
• Relative sizing: If you have delivered a similar epic in the past, use the same size, which is quicker and more accurate.
• Summing up stories: Break the epic into stories, estimate each story, and sum up the efforts of all stories. This technique is used in the “slicing & estimating” phase and typically carries an 80% confidence level.

Planning

Planning epics for a quarter is straightforward.

• Calculate the quarterly velocity of the relevant team(s) by examining the sprints velocity numbers (i.e., summing up the delivery numbers in the last 6 sprints).
• Estimate all epics
• Choose epics that fit within the quarter’s velocity. Account for any exceptional events that might affect velocity in the upcoming quarter.

The confidence in your plan depends on the status of the targeted epics. The more advanced states (e.g., Analyzing, Slicing, Ready for Implementation) they are in, the higher your confidence level. It’s advisable to have a mix of epics at different stages when approaching the quarter’s start date to maintain a steady flow of work and avoid a stop-start pattern. The “stop-start” symptom occurs when you complete all the quarter’s epics, and only afterward, you initiate the discovery phase for the upcoming quarter. This delay leaves the development team idle, waiting for new work to begin.

Monitoring the Overall Progress

Throughout the quarter, it is essential to continuously monitor whether you are on track with the quarter’s content. In order to do that, we need to look on the overall content we have in the roadmap versus the delivery rate.

• Delivery Rate: To gain granular visibility into delivery progress, we should focus on the completion of stories within sprints. This data is constantly updated as teams deliver content, providing a real-time view of progress.
• Overall Roadmap Content: To understand the scope of the content allocated in your roadmap, start by examining the size of the roadmap epics. However, there’s a more precise approach. For epics that have been broken down into stories, use the estimation of the epic’s stories rather than the original epic estimation. Stories reflect refined and up-to-date effort estimates. Here’s how to track effort estimations effectively: for epics in states earlier than “Ready for Implementation,” track the effort estimation at the epic level, and for epics in “Ready for Implementation” or more advanced states, sum up the effort estimation of their stories instead.

As more epics move into advanced states, the total effort estimation becomes increasingly accurate. Additionally, keep a record of the effort estimation for delivered stories. By comparing planned versus delivered effort at various points in the quarter, you can assess whether you’re on track.

Using Jira for Monitoring Progress:
Jira’s FixVersion field is a powerful tool for gathering roadmap data and tracking progress. To effectively leverage this feature, you need to ensure that all epics and stories related to your roadmap are marked with a FixVersion value that corresponds to your roadmap (e.g., “2024-Q4”). By tagging all relevant tickets with this value, Jira’s Release Burndown and Version Report charts can analyze those issues and provide valuable insights.

To populate all roadmap content into Jira at the release level:

• Assign a FixVersion value to all epics that are part of your roadmap.
• For epics that have been broken down into stories, also assign the same FixVersion value to their associated stories.

Jira charts are tied to specific boards, so you will need to create a board with an appropriate filter. This filter should include:

1. Epics that have not yet been broken down into stories (to track high-level planning).
2. Stories for epics that have already been sliced (to ensure detailed tracking of progress).

Once configured, the Release Burndown and Version Report charts will automatically aggregate data from all issues marked with the specified FixVersion. These charts offer critical insights into roadmap progress, helping you predict delivery dates and identify whether you’re on track to meet your goals.

At least once per sprint, review the Release Burndown and Version Report charts to assess whether you are on track. These charts present roadmap data in slightly different ways but serve the same goal: predicting the completion date of the roadmap content. If the projected delivery date exceeds the roadmap’s timebox, it’s an indication that you’re off track.

Taking Action When Off Track:
If you find you’re off track, implement immediate mitigations such as:

• De-scoping content from epics.
• De-scoping entire epics.
• Adding resources to expedite delivery (be cautious of Brooks’ Law, as adding manpower to a late project can make it later).

After applying mitigations, revisit the roadmap charts to ensure you’re back on track.

Visual Example:

Release Burndown Example for 2024 Q4

Version Report Example for 2024 Q4

Monitoring Individual Epics

Throughout the quarter, it is crucial to closely monitor the progress of individual epics to ensure they remain within their allocated budget. This means regularly checking whether the total estimated effort of the epic’s stories exceeds the epic’s original estimation, or “epic budget.”

When an epic runs out of budget, prompt mitigation decisions are necessary. Some possible actions include:

• De-scoping content: Identify and remove lower-priority stories from the epic to reduce its scope and align with the available budget.
• Reallocating resources: Continue working on the epic at the expense of other epics, shifting focus based on overall business priorities.
• Revisiting estimates: Reassess the effort estimates for the remaining stories and adjust the plan accordingly, if feasible.

By addressing budget overages proactively, teams can minimize disruptions and ensure that project goals are met effectively without compromising the broader roadmap.

Dependency Management

Dependencies arise when multiple teams collaborate on development tasks. As a general guideline, when a significant requirement involves multiple teams, it’s advisable to consolidate all related backlog items under a single Epic, rather than distributing them across separate Epics per team. This centralized approach to Epic management facilitates prioritization, effectively handling dependencies among teams.

In instances where two user stories, each assigned to a different team, rely on one another, the objective is to synchronize their development within the same sprint. Such coordination necessitates coordination before the sprint planning event.

When dependencies extend between Epics, it’s crucial to understand their nature. If one Epic must precede another in development, strategic prioritization serves to address this dependency. Conversely, if two Epics require simultaneous development, consolidating them into a unified Epic may be considered. However, if the unified single Epic becomes too big, it’s wise to slice it, not by team boundaries, but rather by distinct use cases, thus ensuring manageable units of work.

Conclusion

In conclusion, effective agile roadmap management requires a well-structured approach that considers granularity, workflow, epic size, estimation, and continuous monitoring. By following these principles, organizations can navigate long-term planning more efficiently and adapt to changing needs.

Release Burndown: Jira Related Boards Configuration

Scrum Board for Release Burndown and Version Report

Within the Jira tool, you can access valuable information automatically through the Release Burndown and Version Report charts. To enable this functionality, ensure you’ve set up a Scrum board using the following filter:

project = XXX AND (type in (story, task) OR type = Epic AND status in (Discovery, Analyzing, Slicing)) ORDER BY Rank ASC

This filter encompasses both Stories/Tasks and Epics in Discovery/Analyzing/Slicing states.

This filter serves as a guide for the board to calculate effort estimations at the Epic level until an Epic reaches the “Ready for Implementation” state. It also keeps track of effort estimations for all stories and tasks within the board.

The Release Burndown and Version Report charts rely on the FixVersion value. To ensure that all quarter Epics have the correct FixVersion assignment, make sure to designate them with the relevant quarter. To extend this value to the Story/Task level, it’s essential to implement Jira automation rules that allow Stories/Tasks to inherit the FixVersion from the Epic they are associated with.

Example of a Release Burndown chart

Example of a Version Report chart

Release Burndown: Jira Related Project Automation Rules

FixVersion: Clear Child FixVersions When Epic FixVersion is Removed (Exclude Completed)

Purpose:
This rule ensures that when the FixVersion of an epic is cleared, all associated child issues (stories or tasks) have their FixVersion fields cleared as well—provided these child issues are not in completed statuses. This keeps the FixVersion field consistent and prevents outdated information from persisting.

Trigger:
The rule activates whenever the FixVersion value of an epic is updated and set to empty.

Conditions:

1. Issue Type Check:
   The issue must be of type Epic.
2. FixVersion Check:
   The FixVersion field of the epic must be empty.

Branch Execution for Child Issues:

• Scope: Applies to all stories or tasks linked to the epic.
• Conditions within the Branch:
  The issue type must be a Story or Task.
  The status of the issue must not be a completed status (e.g., Done, Cancelled, or Duplicate).

Action:
The FixVersion field of each non-completed child issue is cleared.

Use Case:
This rule is particularly useful when an epic is removed from a specific release cycle (e.g., removed from a quarter’s plan). By clearing the FixVersion of child issues, it prevents mismatches between the epic and its child issues, ensuring that only active work is aligned with the current roadmap.

Benefits:

• Improves data accuracy and roadmap alignment.
• Prevents completed work from being unintentionally modified.
• Simplifies reporting by removing outdated associations.

FixVersion: Inherit FixVersion from Epic to Story/Task on Link

Purpose:
This rule ensures that when a story or task is added to an epic in Jira, it automatically inherits the FixVersion value from the associated epic. This maintains consistency across issues and improves traceability in roadmap management.

Trigger:
The rule is activated whenever the parent field (Epic Link) of a story or task is updated.

Conditions:

1. Issue Type Check:
   The issue must be of type Story or Task.
2. FixVersion Update Validity:
   The parent epic must have a non-empty FixVersion value.

Action:
The FixVersion field of the story/task is updated to match the FixVersion of the associated epic.

Use Case:
This rule is critical for roadmap alignment, ensuring that all child issues are correctly tagged to the corresponding quarter or release cycle (FixVersion) without manual intervention.

Benefits:

• Eliminates errors from manual updates.
• Streamlines reporting and tracking for quarterly or sprint-based planning.
• Enhances alignment and visibility in long-term planning.

Set FixVersion 2024-Q4 for Story/Task Moving to In Progress

Purpose:
This rule automatically sets the FixVersion field to 2024-Q4 for stories and tasks when they transition to the "In Progress" status, ensuring accurate version tracking during active work.

Trigger:
The rule activates whenever an issue transitions to the In Progress status.

Conditions:

1. Issue Type Check:
   The issue must be a Story or Task.
2. FixVersion Check:
   The issue must either lack a FixVersion value or have a FixVersion not equal to 2024-Q4.

Action:
The FixVersion field of the issue is set to 2024-Q4.

Use Case:
This rule is useful for ensuring that all active work during a specific quarter or release cycle is appropriately tagged with the correct FixVersion. It automates the process, reducing manual effort and minimizing errors.

Benefits:

• Streamlines the assignment of FixVersion during workflow transitions.
• Ensures all in-progress work is accurately associated with the current roadmap or release.
• Enhances reporting and visibility into active development efforts for a given quarter.

Sync Child FixVersion with Epic on Change (Exclude Completed)

Purpose:
This rule ensures that any changes to the FixVersion of an epic are reflected in its associated child issues (stories or tasks), maintaining consistency in versioning. Completed issues are excluded from updates to avoid modifying historical data.

Trigger:
The rule activates whenever the FixVersion field of an epic is updated.

Conditions:

1. Issue Type Check:
   The issue must be of type Epic.

Branch Execution for Child Issues:

• Scope: Applies to all stories or tasks linked to the epic.
• Conditions within the Branch:
  The issue type must be a Story or Task.
  The status of the issue must not be a completed status (e.g., Done, Cancelled, or Duplicate).

Action:
The FixVersion field of all non-completed child issues is updated to match the new FixVersion of the parent epic.

Use Case:
This rule is essential for keeping roadmap information aligned when epics are moved to a new release or quarter. By syncing child issue FixVersion values with the parent epic, the rule eliminates the risk of mismatches and ensures accurate reporting.

Benefits:

• Automates versioning updates, reducing manual effort and errors.
• Excludes completed work to preserve historical accuracy.
• Enhances roadmap visibility and consistency for all linked issues.

Roll Up SPs to Epic

Purpose:
This rule automatically aggregates the story points (SPs) of all linked child issues (stories and tasks) into their parent epic. It ensures that the epic’s total story points accurately reflect the sum of its associated issues, improving planning and tracking.

Trigger:
The rule activates whenever the Story Points field of a child issue is updated.

Conditions:

1. Issue Type Check:
   The issue must not be an epic.
2. Epic Link Check:
   The child issue must be linked to an epic (the Epic Link field must not be empty).

Action Steps:

1. Lookup Issues:
   The rule searches for all issues linked to the same epic as the triggering issue, filtered by:
   Issue type (Story, Task).
   Status (must not be Cancelled).
2. Aggregate Story Points:
   The story points of all retrieved issues are summed up.
3. Update Parent Epic:
   The accumulated total story points are rolled up to the Story Points field of the parent epic.

Use Case:
This rule is particularly useful for teams that estimate and track work at the story/task level but need to see the aggregated effort at the epic level for reporting or roadmap purposes.

Benefits:

• Automatically maintains accurate story point totals at the epic level.
• Reduces manual effort and potential errors in updating epic estimates.
• Enhances visibility into the total effort for epics, supporting better planning and prioritization.