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.
In the other sections of this guide, we’ve covered all of the tools available to you in Advanced Roadmaps. But thanks to its open-ended nature, it can be difficult to string all of these concepts together.
To demonstrate one way that you can combine all the features available to you, let’s look at how planners at Veridian Dynamics use Advanced Roadmaps.
Veronica is the head of App Development and Feature Delivery at Veridian Dynamics. The company wants to add several new features including a QR reader, a redesigned UI, and a way for users to buy upgrades. To get it done in a timely manner, the work will be split among three teams: the ADR Team, IOS Team, and The Frisky Dingos. Now, it’s up to Veronica to coordinate a timeline.
How Veronica sets up her plan
Veronica starts by creating a plan using the boards that the ADR Team, the IOS Team, and the Frisky Dingo team use as their work sources, respectively:
Then she adds all three of the teams to her plan, and associates the issue sources with the correct teams:
Next, Veronica needs to configure her issue hierarchy to work in the same way for all teams. As it currently stands, only the ADR team uses levels above epic (like Legend and Odyssey). She needs to add those levels to the issue schemes of the IOS team and The Frisky Dingos. To do so, she goes to the Issue Type Scheme page, and adds the already configured issue types to the schemes of those teams:
Once configured, Veronica then makes an Odyssey level issue on her roadmap that aligns with the department’s year-long goal: Continued innovation and refinement. She then adds a child issue at the Legend level called Create new version of app:
By doing it this way, Veronica is setting her plan up to track to the higher level goals of the company, gradually getting more granular and actionable as she goes down in hierarchy level. The Odyssey level ticket is something that other teams within her organization can nest their work under, giving leaders the ability to drill into projects as they see fit.
How Veronica creates her plan
To begin, Veronica creates epics that align with larger sections of tangible work for her teams to handle: one epic for Back end development, another for each feature, one for Front end work, and so on. Once she’s created her epics, she adjusts her hierarchy settings to exclude Legends and Odysseys for now to focus on the work that she needs to plan.
Within each epic, she creates and estimates story-level tasks that represent the actual work to be done, which she then assigns to the teams. She rolls up Dates and Other values in the View settings menu and colors her schedule bars based on the team assignment:
Next, Veronica assigns dependencies to her issues. She tells Advanced Roadmaps that the epic Back End Development can’t begin until all of the work in the epic called Back End Exploration has finished. For now, this is just indicating order for the sake of planning but as the work begins, Advanced Roadmaps shows a warning if this dependency falls off-track.
The last planning structure that Veronica wants to include is releases. She’ll use single-project releases as milestones and one final cross-project release as the final release of the new app. She goes to the Releases tab and creates three single-project releases (one for each team) as well as one cross-project release that encompasses them all:
Now when she goes back to her plan, her releases are marked on her timeline. As her project progresses, she’ll be able to track their progress towards making that release:
The last release on her timeline is the cross-project release, the marker for which coincides with the last release:
From this plan, Veronica is now ready to present her tentative timeline to management as well as product team stakeholders. If it’s approved, All Veronica needs to do is save her changes using the Review changes button in the upper right, and all of the issues that she made on her timeline will auto-populate on the teams' boards ready to be groomed.
Was this helpful?