Teams in Advanced Roadmaps: What's changing, and what you need to know

[#1]

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.

About the Early Access Program

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.

What’s new in Teams?

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.

Changes in Jira Software

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.

When will this be enabled on my site?

(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.

• The first Advanced Roadmaps users to see this change will be Jira Software Premium users that only have one site associated to their org-license.
• Once the change has rolled out to them, we’ll proceed to Jira Software Enterprise users that only have one site associated to their org-license.
• Finally, we’ll roll this change out to users from both Jira Software Premium and Enterprise who have more than one site associated to their org-license.

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.

What do I need to do to prepare?

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.

All Shared teams need at least one member

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:

• delete empty Shared teams before migration that are no longer needed, or;
• add a member to currently empty teams

 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.

Save your changes in Advanced Roadmaps

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.

Will I have duplicate teams after migration?

Most users shouldn’t have an issue with duplicated teams after this migration. However, there’s two situations that may result in duplicate teams:

1. You previously created Atlassian teams in the People tab, and used a separate team in Advanced Roadmaps

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:

                                                               

Which one should I keep?

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.

2. You made duplicate teams across multiple Jira sites

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.

Which one should I keep?

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.

That’s all, folks!

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.

Stay tuned!

[Nikki Zavadska [Appfire]]

This is really great news! Glad to see Teams being reused across Jira, this will be a much better and less confusing experience 👍

[Karin van Driel]

This is just what we are looking for, one team, so that we could actually look at using Atlas going forward also. I'm very excited to see where this goes and sad I missed early access registration :) 
Fingers crossed for a smooth and speedy rollout.

[Hannes Obweger - JXL for Jira]

@Rhys Christian that's huge mate, thanks for driving this.

Could you shed some light on how this will affect any API integrations / the ecosystem? Right now, JXL for Jira (and I'm sure many others) accesses an issue's team via the respective Custom Field, assuming a certain data shape. Will this change?

Cheers!

[John Elder]

This is a terrifice advancement, for sure.  Just need to incorporate Tempo teams now, for those of us using time tracking/timesheets as well.

[Karin van Driel]

+1 for incorporating Tempo teams :) 

[John Haworth]

What is the impact of this change on capacity management. Will team members have individual capacity per project? Or does the team have a capacity as a whole spread over multiple projects?

I know we were hoping for more team member capacity planning ability 

[John Elder]

I really like John H.'s comment regarding team member level capacity planning.  We are just getting into this in our office and while we use Advanced Roadmaps for team planning and generic capacity/sprint slotting, we are struggling to connect the dots with the capacity of individuals (hours) and the stories/sub-tasks... some combination of Tempo Planner and Jira, but it would be AMAZING to incorporate this concept into Roadmaps, if at all feasible.

[Karin van Driel]

Yes, I agree with both John H and John E that it would be great to allow us to link in capacity planning into our Plan, even if it is through the use of an App like Tempo. This I think was a benefit of Jira Portfolio, that didn't get carried into Advanced Roadmaps and is something we are missing for comprehensive planning, as currently there is no easy way to reflect change in Team capacity due to holidays etc.

[John Haworth]

I don't want to detract from the work that has been done here and spiral this in to a change request conversation, which seems to be a tendency of posts on Atlassian threads.

My thinking was this. If you are looking to capacity plan per person using advance roadmaps it it possible if you create 1 team per assignee. Work has to be assigned in advance of each sprint and you can adjust each persons capacity per sprint. (a few automations auto change the team when the assignee changes to keep the admin low) This has worked for us, but its very much a 'not as intended' user case. The thing with sharing teams across plans is you have to have an understanding of how much time is utilized in each plan otherwise you can use 100% in both plans and things fall apart. Advance roadmaps is already set up with sprint capacity planning tools per team so I'm assuming there has to be some way of preventing over planning team resource when these teams are shared. 

Shared teams is a great feature I was hoping that its existence points to a solution to the work around we are currently using (rather than add to the number of posts asking for new scope) 

[Karin van Driel]

Hi @John Haworth - 
Thanks for that insight, but how do you then vary capacity of that person over time (e.g. if they take a few days off)? That is the piece I'm missing. I'm not even stuck on managing that at the individual's level. It could be a change in capacity per sprint going forward, if needed. I have not found a way to do this, so if you have, I'd love to hear about that :). 

As for planning across multiple plans, I would expect the new 'global team' to have visibility of all work assigned to the team and track that against their capacity, so that it would identify if no/less capacity is left for that team in a second plan. I'd imagine this would only happen once a change in plan was committed though. But maybe that is not how it will work. I guess time will tell :) 

[Rhys Christian]

Hey @Hannes Obweger - JXL for Jira - Chris left a comment in the other blog post for you about the technical changes. I understand the expectation is that it should be compatible with your app, though the exception may be if you rely on the custom field type. Chris is the best person to follow-up with if you have further technical questions.

In order to assess the impact on your app directly, we can add you to the early rollout program. We're not accepting new customers to the program but we can include you as a vendor.
If you're interested, please sign-up via the form in this article: https://community.atlassian.com/t5/Advanced-Roadmaps-articles/Advanced-Roadmaps-Team-unification-Sign-up-to-take-part-in-the/ba-p/2084987

Note: the site you provide for early rollout is required to be a production instance.

Cheers,

[Hannes Obweger - JXL for Jira]

Thanks @Rhys Christian, I've signed up our dev instance. Looking forward to trying this out!

[John Haworth]

@Karin van Driel Navigate to the sprint capacity plan in roadmaps You can edit the default sprint capacity (seen here as 6 days) so In this case if someone had 4 days holiday in a 10 day sprint this lets you adjust the capacity for that sprint. 

[Karin van Driel]

@John Haworth - Thank you, thank you, thank you! I hadn't realised that field was editable! Really appreciate you sharing that :)
I'm all good to go then, thanks again.

[sharon.warner]

Hey this sounds great! I also didn't know about the Sprint Capacity editing capability, fantastic!

I am curious how the members of the teams will be able to be used moving forward?  Will we be able to create a basic org chart of teams, members and titles or filter the members into Confluence, etc?  

Thanks

[Vanessa.AmbrosioDaSilva]

Is there a plan to incorporate Activity Timeline's team, or ope the API for this application?

[Nick Wolf]

Is there more information available about the administration of Atlassian teams?  This was the only resource I could. It appears that the ability to create & edit teams is open to all users without the possibility to restrict on the admin side.  Will this update deprecate the Shared Team Management permission setting in Jira?

We recently added Advanced Roadmaps and are working toward capacity planning, but I would be nervous if there wasn't some control available over CRUD of the teams.  If a user deletes a team, what happens to issues with that team assigned?

Also, will all teams everywhere be selectable in the team field?  The only current use case where we've utilized teams before is to be able to @ mention a team, but in a lot of cases we wouldn't want teams created for that purpose used as the team assigned to tickets (especially if it isn't a multi-select field) from a capacity management standpoint.

This is definitely an improvement over the two entities being completely separate.  If the Atlas team is able to deliver on allowing Atlas Projects to integrate with issue types other than Epics (e.g. Initiatives), that product will become very useful to the Advanced Roadmaps crowd!

[Bhish]

Does this mean better first-class support for teams in Jira? Right now it is not supported in things like, automation, for example

[David Booth]

Will this change allow Child Issues to have 2 parents? We use advanced roadmaps constantly, across many teams, and it would be LOVELY to have a child issue have 2 parents!

[Anne Warmer]

Why does Atlassian never consider bigger customers? 

We have one big organisation, with several different companies. Each one has their own site. And I do not want the other companies to see our shared teams. This is really bad.

[Alan Williams]

If you "@" mention a team will it email the members of that team?  Asking for a friend......

[Gregory Kremer]

@Rhys Christian This is somewhat a bitter-sweet announcement as far as our organization is concerned. We did a lot of work to navigate Team field's shortcomings. The announced changes will cause us a lot of headaches. That being said here are my questions:

1. Will we be able to control who can create a Team in the new setup?

2. We have a large number of reports, based on Team field. Currently, as everyone knows, we have to use team number in order to extract relevant data. Will team numbers be still available and will remain the same in the new setup? This is crucial for us to know, as all the reports would need to be re-written in case team numbers are changed or completely gone.

I will greatly appreciate your prompt reply.

[Naman Naik]

All I can say that this is just a great from collective ownership point of view. Rather than assigning to individual, it looks great that team will be assigned to issue and they can manage work forward

[Doug Levitt]

When will we have the capability to assign a Jira Group to a Team.  We really need an integrated way to manage sets of people.  This way, we can use one Group for managing permissions and Adv Roadmaps Teams.  Thanks.

[Rachael Williams]

Will you finally be able to query by the team name rather than the ID?  Or will you expose the ID in some way so that teams can figure it out without having to simulate a query?