You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Update: August 2nd
We're excited to share that rollout of our Team unification will be resuming soon, in the coming weeks, for Jira Software Premium customers which will be followed by Enterprise editions.
Rollout will be progressive across user-tier and edition cohorts, so we can't confirm ETAs for any particular group or customer. See the "When will this be enabled on my site?" section below for some more details.
We’re pleased as punch to announce that we’re launching an Early Access Program that combines the Shared teams in Advanced Roadmaps with the Atlassian Teams in Jira Software so you can use the same team in both places!
For now, this feature is only available to Advanced Roadmaps customers enrolled in the Early Access Program. But fear not: if all goes well, we hope that this change will roll out to all Advanced Roadmaps users after that.
All Early Access Program participants will be invited to a private community group. We’re super keen to hear how the rollout goes for you, and what (if any ) issues you’ve had as a result. This rollout has big implications across the Jira Software product as well as Atlassian as a whole: once live, this will add tons of value for the rest of our customers allowing you to use one team across all Atlassian products.
In this community post, we’ll be covering what’s changing, when you might see this change on your site, what you need to do before and after the migration, and how to give your feedback.
Previously, the details and membership of a Shared team were only visible in Advanced Roadmaps and nowhere else within Jira Software. We’ve heard the feedback from customers who are unhappy with aspects of this. As part of these coming changes, Teams will be easier to setup, and a single Atlassian Team can be used across Atlassian tools, (rather than needing a bespoke Team for Advanced Roadmaps).
So in an effort to unify the teams across Jira Software (and later
the world all Atlassian products) we’ll be migrating all Shared teams in Advanced Roadmaps to the new Teams platform. After this change rolls out, you’ll be able to use the same teams in Advanced Roadmaps and Jira Software. All of your teams will now be available by navigating to the People tab > Search people and teams. No more double configurations, no more siloed teams – just smooth sailing.
|Plan-only teams in Advanced Roadmaps are not effected by this change.|
There’s a lot of benefits to this transition on the Jira Software side as well, and we encourage you to read the companion post to this one: Atlassian Teams are coming to Jira!
The Teams field will be automatically added to your issues in Jira Software if you’d previously configured a custom teams field in Advanced Roadmaps. This new field will automatically replace it. Otherwise, you can add the Team field to your issues via the Field configuration.
(Updated 1 Aug): This change will be rolling out over the next few months. We expect most customers to be upgraded by the end of 2023. As stated on our public Cloud roadmap.
If you’re not sure which of these groups you belong in, the main change to look out for is whether you see the phrase “Shared teams” anywhere on your Teams page. If you do, then the change hasn’t come to your site yet.
After the migration, your Shared teams will be visible across all Jira sites in your organization (even if your organization uses multiple sites). If you have any cheeky teams that you don’t want your entire org to see, we recommend that you delete them before the transition happens.
Otherwise, the transition will be done automatically, so most users won’t need to prepare anything. But there are some edge-cases you may want to be aware of.
One of the conditions of migration is that all Shared teams need to have at least one member after they migrate. If your site contains empty Shared teams, you’ll see a icon next to View Shared teams next to the the Plans dropdown about six weeks before the migration. At this stage, we encourage you to add a member to any empty Shared teams.
Once you’re within three weeks of the migration, any remaining Shared teams with no members will be assigned a default member, but you can choose a different user. If this solution is less than ideal, then we encourage you to do either of the following instead:
Why did we choose this approach?
We debated simply not migrating empty Shared teams, effectively deleting them since our analytics suggest the majority of them have never been used for planning. However, there are many that are used frequently, and deleting them would ruin several users' plans.
This approach preserves the empty teams that are being used while also giving users the chance to delete any unused teams they don’t want to keep.
If your plan doesn’t contain empty Shared teams, you’ll see an icon. On the Shared teams page, you’ll see an information box explaining what’s about to happen, but no action is required.
When the migration happens, any unsaved changes to team assignments in Advanced Roadmaps may be lost. The simple solution to this is that you commit any unsaved changes, particularly any team reassignments, using the Review changes modal.
Most users shouldn’t have an issue with duplicated teams after this migration. However, there’s two situations that may result in duplicate teams:
The teams that migrate from Advanced Roadmaps will not replace any existing teams in the People tab. You can tell which team’s been migrated by the roadmaps-y header image:
If you have duplicate teams after the migration, we recommend keeping the team that migrated in from Advanced Roadmaps and deprecating the old Atlassian team. This is because the migrated team will be attached to all of your Jira data from Advanced Roadmaps. In the grand scheme of things, it’s easier to reassign the new team to other Atlassian products than it is to reassign all of your Jira data to your old team.
After the migration, we recommend that you replace the old team with the newly migrated team as quickly as possible. If your organization needs time to verify which teams should be kept, or if you expect a long overlap window between migration and removing duplicate teams, consider adding a prefix to the front of the old team’s name (such as [OLD] or [DO NOT USE]) to prevent users assigning new Jira issues to the wrong team.
Before you delete your old teams, we recommend that you use JQL to confirm that all of the issues have been assigned to the team you’re keeping.
One of the biggest conceptual shifts with this migration is that Atlassian teams are created at the org-level while Advanced Roadmaps teams were previously created at the site-level. If you made the same team across multiple Jira sites, all of those duplicate teams will now be housed in the same container.
For example, Wensleydale (the team driving this migration) plans their work in the site JDOG. However, other teams may also have created a Wensleydale team in their Advanced Roadmaps sites for project planning purposes. After the migration, all of these teams labeled Wensleydale will be visible from the People tab in Jira.
You’ll want to keep the team that’s assigned to all of the correct Jira data. To decide which one to keep, navigate to the Teams page (People tab > Search people and teams) then select one of the duplicated teams. On the team’s information page, you’ll see which issues this team has been assigned. Find the team that’s assigned to the correct issues, and add a prefix of your choosing (but something unique) to indicate that this team is the one you want to keep. This makes it easier for you to delete the duplicate teams after migration. However, before you delete it, we recommend that you use JQL to search for any remaining issues assigned to the old team before deleting it.
We’ll update this page as the early Access Program progresses. We’ll share any blockers that we find that’ll impact our timeline or (hopefully) a date when you can expect to see this across all of Jira Software.