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

[Zsuzsanna Varadi]

We are happy about this! :) Thanks a lot.
@Rhys Christian who is part of the early access program? Where can I check if we are part of it?

[Rik de Valk]

Hi @Rhys Christian , 

Thanks for the update. Absolutely fantastic that Atlassian is improving the Teams concept in  the suite. Especially since 'teams' are at the core of each Atlassian product. 

I would be really excited when: 

1. Admins can manage the permissions for managing Teams, so that this function can be restricted in organisations that apply strict mechanisms for team-organization
2. A Team multi-select field is introduced, so that admins can choose for single- or multi select Team fields. This will be really useful for larger bodies of work (Epics, Initiatives)
3. The Team field can be set / used in Automation Rules
4. Teams from Advanced Roadmaps and Jira Software will also be merged with Teams in JSM / OpsGenie
5. Teams of Teams are introduced (similar to what a project-category is for projects)

Is there a roadmap available for the evolvement of the Team concept across Atlassian products? 

Have a nice day! Rik 

[Dianna Bucher]

Our organization has multiple projects in Jira; one project per application.  Are there plans to allow the Teams dropdown in Jira to limit the Teams we see in the dropdown to those in the Jira project similar to the Sprint dropdown?

[luke.greenwood]

@[deleted] when will this change be implemented for folks that are not in the early access program? I'm thinking about implementing Atlas and need to know timing so I don't end up creating duplicate teams. Thanks!

[Doug Levitt]

• The Team field can be set / used in Automation Rules

I 100% agree.  Within Automations, using conditions on Teams or setting/editing Teams, while doable, results in "code" which is not supportable (well, by anyone but me). 

[Bhish]

An additional feature that would be really good is if the team field can automatically be assigned during ticket creation based on the board you are viewing. We are in a company-managed environment, with several SCRUM projects setup, one per team, the filter on these boards are "where Team = X". The POs of each team will spend time on their backlog & roadmap view and create tickets directly from these interfaces by using the "Create ticket" rows, but when a ticket is created it is immediately hidden from the view (because the Team value is set to empty).

Sometimes JIRA seems to be smart enough to infer fields based on the existing filters; for example, filtering by epic in the backlog view and creating a ticket will automatically assign that epic, but it is not that intelligent for Team fields

[Erki Tammik]

We need groups to manage teams; otherwise, it creates a lot of manual work to keep teams up to date. I'm bit surprised that it hasn't been implemented.

When can we expect this feature to be released?

[Mohamed]

What a great news! very happy to hear this is going to be very helpfull.

[Rhys Christian]

@John Haworth 

“What is the impact of this change on capacity management?”

I should provide some expectations here and note that the main outcome of this work is to ensure Advanced Roadmaps works with this new Team concept with minimal loss in productivity.

It won’t provide new functionality or have any changes to functionality like Capacity planning. However your feedback around individual capacity is much appreciated and we’ve collected it for consideration - this need is high on our radar. 

So the way that Team capacity works today will be unchanged.
That said, there will be some new value offered with the unification outside Advanced Roadmap (e.g the Team profile surfaces very useful info, and the team can be used in @mention). With more to come.

“If you are looking to capacity plan per person using advance roadmaps it it possible if you create 1 team per assignee. “

This will still be technically possible, but I’d advise using ‘Plan-only teams’ for this use case so that your Teams doesn’t overpopulate with proxy “individual teams”.

[Rhys Christian]

@Vanessa.AmbrosioDaSilva 

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

I’m not familiar with Activity Timeline. They should be able to continue to leverage the APIs we offer today.
I’d be interested to hear more about how you suggest Teams and Activity Timeline could be leveraged together.

[Rhys Christian]

@Nick Wolf , @Gregory Kremer , @Rik de Valk , @Anne Warmer

“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?”

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

Administration of teams will not be available in the new Team concept after unification. The Shared Team Management permission settings will be deprecated. This is essentially a fresh start for providing Team as a global Atlassian concept, and therefore this is an area that will be less mature at GA.

There won’t be control over who can CRUD teams. Issues assigned to the team will be removed on deletion. We’d be very eager to hear more about this need for you so we can capture these requirements for the new owners of the Team field while they plan their Post-GA roadmap.

Can you please explain in more detail how the lack of permissions for Team CRUD impacts you and your organisation? What are the concerns and potential risks? 

The more feedback I can surface internally about this need the better! Thank you

[Rhys Christian]

@Gregory Kremer 

“Will team numbers be still available and will remain the same in the new setup?”

We’ve made the Team API and ID backward compatible so they should continue to work in existing reports. The ID format is changing from a single integer to a longer value… but this should not break your existing reports.

We’re confident about this, but just so we can verify specific cases can you please provide more info on you Report setup so we can test the scenario?

[Rhys Christian]

@Nick Wolf 

“will all teams everywhere be selectable in the team field? “

Yes all teams will be selectable. Technically it will be the same field Advanced Roadmap uses on issues today, but the teams in that selection will all come from Atlassian Teams following the unification.

This is also be the same Team concept that is used in Atlas. The plan is for this Team concept to be shared across multiple Atlassian products - it didn’t made sense for such an important and general concept to be exclusive to just Advanced Roadmaps.

[Rhys Christian]

@Bhish @Rik de Valk 

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

Over time yes this is expected as it will have a dedicated focus rather than a feature under the Advanced Roadmaps umbrella.

Automation won’t be natively supported at GA though.

However, automation can actually be used with Shared teams today (not easily, and using the “more options”) - you can read up on it here: https://community.atlassian.com/t5/Jira-articles/Automation-Set-your-Advanced-Roadmaps-Team-automatically-when/ba-p/1761588

We’ve done work to make our APIs backwards compatible so they should continue to work post-unification. 

[Rhys Christian]

@David Booth @Rik de Valk 

“Will this change allow Child Issues to have 2 parents? “

@David Booth  -I assume you mean 2 “Teams” (i.e Multi-select) as this post isn’t related to Parent issues, is that right?

Unfortunately no this won’t be provided as part of the unification. That would be quite a foundational change with some knock-on impacts. I’d be interested to know more about your need for this. Can you please describe your use case?

Something that might be considered could be a custom Team field that uses Atlassian Teams. If there was a way to have 2 Team fields do you think this would help you?

[Rhys Christian]

@Alan Williams 

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

Yes, @mentions should email those members. I’m not sure if there’s global or user-level permissions that manage emails notifications - but emails should be provided by default. Is this good/bad for you (...or your friend?)

[Rhys Christian]

@Doug Levitt 

“When will we have the capability to assign a Jira Group to a Team”

 Unfortunately, there aren’t plans for this presently. We’d be interested to hear feedback you can offer about needs around Team permissions.

[Rhys Christian]

@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?”

Not immediately. However the team owning ‘Atlassian Teams’ is planning to support Basic search so you won’t have to search for team ID. I can’t provide a timeframe on when to expect this to become available though.

[Rhys Christian]

@Zsuzsanna Varadi 

“who is part of the early access program? Where can I check if we are part of it?”

This is a closed EAP that we’re running with ~20 customers atm so it’s unlikely you have it yet.

The easy way to check is via the ‘Plans’ dropdown. It won’t include any mention of “Shared teams” anymore.

[Rhys Christian]

@Rik de Valk 

Thank you for your feedback! Glad to hear the excitement. I’d really love to capture in more detail your needs around “Permissions for managing teams”. The more feedback I can surface about this need the better!

“Teams from Advanced Roadmaps and Jira Software will also be merged with Teams in JSM / OpsGenie“

 This is planned :) 

Team-of-Teams are not planned unfortunately. But this is a great suggestion.

I believe this is the only public roadmap item related to Teams at the moment: https://www.atlassian.com/wac/roadmap/cloud/unification-of-our-team-concepts?search=unifi&p=3e20b18b-bc

[Rhys Christian]

@Dianna Bucher 

“Are there plans to allow the Teams dropdown in Jira to limit the Teams we see in the dropdown to those in the Jira project similar to the Sprint dropdown?”

No there aren’t plans for this. There will be some smarts in the suggestions in the dropdown - i.e Teams you are in will default to the top. The team will consider additional smarts when there’s more data / feedback to discover the remaining challenges.

[Rhys Christian]

@luke.greenwood 

"when will this change be implemented for folks that are not in the early access program?"

Free/standard licenses are starting to get the updates for the Team concept now. It's early in the rollout so far. Free/Standard have not had access to Teams before so this is less of a unification for them.

Premium rollout is expected to be in the coming weeks (so long as there's no issues) and rolled out over a duration of ~3 weeks. However we’re constantly assessing go/no-go so I can’t be definitive about when. Enterprise is planned for a bit later than Premium. Sorry I can’t provide more specific timelines.

[Karin van Driel]

Wow @Rhys Christian I came in to a lot of updates this morning, thank you!

I didn't see anything on the possibility of having the Teams be unified with Tempo Teams; is that something we should check on with Tempo's vendor instead?

I'm a little sad that Enterprise roll out is last, I'm holding off on rolling out Atlas at the moment to avoid adding complication for the unification. We only recently migrated to cloud, so we only really use Shared  teams in Advanced Roadmaps at present. 

It would be good to add some permissioning around Teams management, especially for the updating of team capacity I think. Also a little worried that someone could accidentally delete a team, as not all of our users are very proficient in Jira. If not driven by permissions, just providing some kind of protection around delete would be great.

Thank you for the article on Automation, I was struggling to know how to use the 'more options', so this is great!

Looking forward to having access to the new unified Teams, thanks for the work on making this more usable.

[Doug Levitt]

Hi @Rhys Christian 

“When will we have the capability to assign a Jira Group to a Team”

 Unfortunately, there aren’t plans for this presently. We’d be interested to hear feedback you can offer about needs around Team permissions.

As far as I understand, the core of Atlassian permissions are Atlassian Users and Atlassian Groups.

I wish:

a) Atlassian Groups included not just a list of users, but the capability to identify the role of the user in the Group.  As an example, I create an Atlassian Group for each of our Scrum Teams.  We use these Groups for Jira Project permissions.  It would be great if I could distinguish, with an Atlassian Group, who is the Scrum Master, who is the PO and who are the Developers.

b) I use the Confluence "User List" macro to display who is on which Scrum Teams.

c) It would make sense, to be able to set the Teams list to reference an Atlassian Group.  Why would Atlassian purposely require its customers to maintain the same information in multiple components?  It doesn't make sense (to me).

d) It would make sense, to enable an Atlassian Group to include other Atlassian Groups (in a nested fashion).  I have a group for people who are Developers in Division 1 and another group for people who are Testers in Division 1.  I would like to create a Group that spans all people in Division 1. 

Right now, it appears that Atlassian Product Owners are not visualizing usage end-to-end (across its multiple products).  That is, there is a component for User/Group management, a component for Jira Permissions, a component for Team permissions, etc.

From a user perspective, it seems like the product is mostly designed for the simple/vanilla use case - single team/single product.  But, doesn't Atlassian want to support product development @ scale (multiple teams working collaboratively on a single product)?  Or, is that not something Atlassian is interested in fully supporting?

Thanks,

Doug

[Rachael Williams]

@Rhys Christian - regarding Team management and permissions, we had the following issues in the last company I worked for:

• Duplicate teams were often created, nothing prevented this
• The only differentiator between duplicate team names was the Team ID but that wasn't visible from the Teams list.  Deleting or renaming the duplicate was a guessing game
• Team level Boards were created by using filter queries and leveraged the Team field to tag work to Team 1, 2, etc.  Modifying someone else's team could impact someone's scrum board
• From Plans > Shared Teams, it is very easy to delete a team.  Just click the x and confirm.  Like above bullet point, this could heavily impact a scrum team who used the team field for their scrum board where everything would go missing.