Learn how to set up Jira Software Cloud and integrate it with other products and applications.
Learn how to configure your Jira Software Cloud company-managed projects to suit your agile development processes.
Learn how to create, search, and work with issues in software projects, manage your profile, and more.
Learn how to get started, enable features, and manage and administer team-managed projects.
Plan and view work across multiple teams, projects, and releases with Advanced Roadmaps.
A guide on how to deploy and monitor an application built on AWS using Atlassian and third-party tools.
This page refers to Advanced Roadmaps, which is a cross-project planning tool only available as part of Jira Software Cloud Premium and Enterprise.
We have a separate section for documentation about the project roadmap that’s included in all Jira Software plans. Go to the documentation for project-level roadmaps in Jira Software.
Advanced Roadmaps is designed to help you create high-level plans for your organization, and comes with tools specifically designed for long-term planning that don’t exist elsewhere in the Jira ecosystem.
Parent issue and child issue are relative terms used to refer to higher-level issues that contain smaller tasks. This concept scales to any hierarchy level:
an initiative (parent issue) that contains epics (child issue)
an epic (parent issue) that contains stories (child issue)
a story (parent issue) that contains subtasks (child issue)
A big problem for planners is that what you plan isn’t always what ends up happening. Instead of forcing you to manually update values of parent issues, you can tell Advanced Roadmaps to infer values of parent issues based on those of the child issues. In Advanced Roadmaps, this is referred to as a roll-up.
From the View settings menu on your timeline, you can choose to infer any of the following values:
Estimations and custom number fields - Learn more about how Advanced Roadmaps rolls up estimates
Releases, sprints, and teams
This feature is currently rolling out to cloud customers. Your site may not reflect these changes, or you might not see it in your site just yet.
Rolling up dates is a calculation that only exists for planning purposes in Advanced Roadmaps. When you commit changes back to your Jira issues, rolled-up values are saved as a static number or text as if they’re manually set. This value stored in your Jira issue will not dynamically update as your plan evolves.
For example, let’s look at the screenshot below:
The top level issue is an epic, and contained within are three stories. With rolled up values enabled, Advanced Roadmaps automatically picks the earliest start date and the latest end date of the child issues, then applies them to the parent issue. This way, if the child issues get rescheduled, delayed, or removed from your plan (which happens; no judgement), the values of the epics automatically reflect this and keep your plan on track.
As your plan grows and changes, Advanced Roadmaps will alert you to any errors in your plan by turning the row yellow, and adding a warning icon in the Scope column. These warnings indicate inconsistencies in your plan like misaligned dates, overlapping dependencies, missing sprint assignments, and more.
Advanced Roadmaps can automatically schedule issues for you based on any information that you’ve already added like issue estimations, scheduled issues, dependencies, release and team assignments, and more. From here, you can either commit the plan as is, or use it as a starting point to make further edits.
Capacity and velocity
Capacity and velocity in Advanced Roadmaps are two features that help you create efficient but achievable plans.
Capacity in Advanced Roadmaps refers to the number of story points or hours your team can complete in one iteration. For example, a team with a capacity of 30 story points (which is the default setting) can contain six issues that are estimated at five story points each during one iteration.
Velocity, which is used strictly for planning purposes in Advanced Roadmaps, is your team’s average capacity per iteration over time based on past performance. For example, a team with a velocity of 30 story points will require two sprints to complete an epic estimated at 35 story points, assuming no other work was already assigned to those sprints.
Together, these two features ensure that your plan is realistic based on how quickly your teams are able to work.
Was this helpful?