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

[Alex van Vucht]

Will these changes to the Team field also satisfy [JSWCLOUD-20787] Team field not supported for sorting on gadgets?

The Team field in Data Center is supported by gadgets as, since Advanced Roadmaps 3.10, Jira Data Center returns the Team field on requests to the /rest/gadget/1.0/statTypes endpoint, so dashboard gadgets allow the Team field to be used in gadget statistics. We recently migrated from Data Center so it's a sore point for our users that the Team field is not available for our dashboards in Cloud.

[Jordan Wilkinson]

"Soon" = when?

[Karin van Driel]

@Jordan Wilkinson ,

There's a comment on the second comments page from @Rhys Christian :

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

[Walter Buggenhout]

Hi @Rhys Christian,

Having a central team concept across the board feels like filling a major gap for a company that has "unleash the potential of every team" as its mission statement. So very happy to see this major step towards that taking place.

Since the concept was missing in the past, however, nearly every organisation we work with (as a solution partner) has found custom ways to work around that. Marketplace apps in strategic areas (like Tempo for time tracking/planning) have built their own teams concept because it was simply needed. As I would like to help our customers prepare, I would be very happy to see an overall roll-out plan that also includes the way forward to consolidating this feature change (which in the end will be a huge step forward across the board, I reckon). I'd be happy to participate in helping that take shape, if that might not be available yet and if that might be helpful.

Apart from that, I have a couple of questions about this announcement post - I did scan the thread but may have missed a few things; if so, sorry for repeating things.

Previously, a Shared team in Advanced Roadmaps was only visible within plans and nowhere else within Jira Software.

I don't think this is true. In JSW premium, the teams field is available and does display the list of shared teams on Jira issues where the field is added on the screens. I am not sure what you mean by this (and it is probably not very important, but just wondering).

The biggest news for Advanced Roadmaps users is that 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.

I would really like to understand what this means in practice:

• The current advanced roadmaps Team field is not configurable, as far as I know and available out of the box on the premium plan, so what custom teams field are you referring to?

• The statement "... field will be automatically added to your issues in JSW ..." means that the field will suddenly appear on all screens across all issue types? Or does this mean it will replace the current Team field where it was already configured? In existing instances where we use the field, there are issues / issue types where we need the field, but others where we don't need it. I sincerely hope that the field will not be pushed on every screen automatically, as that will lead to users seeing information they don't need when creating issues and a step back in terms of usability / user friendliness.

One of the conditions of migration is that all Shared teams need to have at least one member after they migrate.

Maybe I am missing a point here, but Advanced Roadmaps has moved away from adding team members to teams since live plans to manage capacity at the team level. Adapting to that change, advanced roadmaps teams in most environments do not have team members in them. Some of our customers literally have dozens of teams, which means quite a lot of unforeseen update work across their instances. Having worked with previous versions of Advanced Roadmaps and Portfolio for Jira in the past, managing team members in teams simply did not scale (unless you find ways to import/update the information easily). What is the view/plan in that area?

In summary, I really welcome the change (and the possibilities behind it), but we need solid information to share with customers about the transition. I believe it has major impact on the way work is being managed inside organisations. It is not something you'd want to suddenly appear in your cloud site overnight and break things. 

Thx for a heads up!

[Rachael Williams]

@Rhys Christian - we are on Premium and started seeing the rollout last week.  We see "Teams" now on the main menu and it looks like a full migration from what was on Plans/Advanced Roadmaps/Shared Teams.  

However, now it is unclear where we need to create new teams and maintain teams.  The "Team" field on our issue types are still being driven by Plans >Shared Teams.  We created a new team from Teams > "Create a team" but we don't see that new team in the list, so we continue to use the old approach.  Is the rollout not fully complete?

From a change management perspective, I'm hoping to get some more information on these questions

• where do we create new teams?
• what field on the issue type will be linked to the teams list?
• do the site admins need to make any changes?
• will the Plans > Shared Teams feature be disappearing at some point?
• Is there any other functionality built into the Teams feature or is it mainly having the @mention?

[Jen Elam]

@Rhys Christian Is there any plan to allow deactivation of a team? 

We have been using some sort of team field for years (custom and advanced roadmap).  Over the years, some teams have been retired.  In our custom field we have disabled the values for those teams so that they don't show up in the select list.  We would like to keep the history of these teams but not have them show as selectable.

I do like the field defaulting to show teams you are a member of first but I would still like to be able to hide teams from selection.

Restrict deleting of Teams - Use Case

If deleting a team removes that value from all issues, this would be a huge No for us as an enterprise company.  There would be nothing to prevent any old user from deleting a team accidentally and then removing the field value from thousands and thousands of issues?

I could see this happening if the teams are shared across instances and suddenly teams from other instances show up in the list and someone hits delete.

Control which instances a Team appears in

As an enterprise company with multiple Jira instances, I would also like the ability to control which instances a Team shows up in.  I can see that it will be confusing if Teams start appearing in instances that they don't work in.  It will also make the list of teams really long.

[Erki Tammik]

I'll share my quick thoughts on this.
In my opinion feature is half-baked, and without control, it can create chaos.

Groups

• we need groups to manage Teams - why do we create more manual work when we already have groups.? We already have groups that we could use for Teams

Teams management

• admins need to have control over Teams, otherwise we end up with similarly named and duplicated Teams, just like what happened with statuses when users used the Simplified workflow on boards
• only admins should have the ability to create/delete Teams
• options to set teams visibility - not all the Teams should be visible for everyone

Teams

• Shared public teams - can only be managed by admins
  By default, each project in our instance will have its own dedicated Team, for sharing work between different projects
• Internal teams (something like plan only on roadmaps) are intended for users who want to manage their own small teams
• In order to enable this feature, you may have to transform the Team field into a multi-select field

[Gregory Kremer]

I absolutely agree. I would go even further than that - JIRA admins should be the only ones with the ability to create Teams. In short, Admins need full control over Teams, period.

[Rhys Christian]

Hey @Karin van Driel

Thanks for sharing you feedback.
Tempo is an interesting topic. No this work won’t unify with their teams.
We’ve had Tempo involved in the the EAP to make sure our changes don’t break anything across their apps. While it’s not currently used in Tempo timesheets, they may further consider support now that our Teams becoming more broadly used and native across Atlassian tools.

"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’re working on some challenges with Enterprise which is the reason it is latest in the rollout. We’d be interested in your insight that may be relevant. The main challenge we’re looking at addressing relates to the fact that Atlassian Teams is a Global concept - so Teams become visible across sites with extended visibility/access. 
This has been raised as an issue among ‘conglomerate’ organisations - where there are independent companies within a shared Org license. Is this something that resonates or raises concerns for you? (We are investigating options to resolve this concern).

Your feedback on this would be valuable. If this issue I explained doesn’t impact your organisation we may be able to prioritise your organisation higher in our Enterprise rollout. Could you please contact our support so they can connect you with our engineering team? They can ensure you’re among the priority for Enterprise rollout.

[Rhys Christian]

Hey @Alex van Vucht

"Will these changes to the Team field also satisfy [JSWCLOUD-20787] Team field not supported for sorting on gadgets?"

This won’t immediately provide new gadget support. However I expect the more native support of Atlassian Teams among our core concepts will further emphasise the need for it to support Gadgets.

To further inform this feedback, could you please explain more about the gadgets your users miss and their use cases for them?

[Rhys Christian]

Hey @Walter Buggenhout ,

Thank you for your feedback.

"I don't think this is true."

I have made this content clearer, to reflect that the Team information (i.e the team profile information / membership etc.) was previously difficult to discover and only accessible from Advanced Roadmaps areas in JSW.

"Advanced Roadmaps users is that the Teams field will be automatically added to your issues in Jira Software"

Good point, this also needed clarification.

• Issues that have the Advanced Roadmaps Team applied today will still have a Team field, but it will be the Atlassian team field (which includes teams migrated from Advanced Roadmaps). Technically it’s the same field, but the source is what’s really being replaced.
• The team field will not be forced on issues automatically. The Team field will be available to add to issues via the Configure option on issues. 

"Advanced Roadmaps has moved away from adding team members to teams since live plans to manage capacity at the team level"

While Team membership doesn’t offer a lot of value in a plan (there is still some, but very minimal), the concept of Team members will have use beyond Advanced Roadmaps capabilities. For example when @mentioning a team, it will also mention all members in the team.

There also may be future value offered for Team members in the future for Advanced Roadmaps. e.g while not on a roadmap currently, we have an appetite to deliver functionality around team member availabilities. We’d be very interested to understand the team management/maintenance and scaling difficulties you have encountered to help inform the Team on how this can be improved.

[Rhys Christian]

Hey @Rachael Williams

"we are on Premium and started seeing the rollout last week. "

Unless you are among a small number of customers our closed EAP I don’t expect you to have the Teams unification yet and we haven’t started rolling out to Premium customers.

You can verify from the Plan dropdown which would no longer have a “Shared teams” option. Individual Team settings in Advanced Roadmaps will also look different, with a banner and link to the Team profile. Can you confirm this?

Regarding your questions - after migration:

• you can still create teams from within plans, or from the Atlassian Teams home (“People & Teams” in the People dropdown).
• The field is simply called ‘Teams’, and should be among fields you can add to your issues.
• Site admin shouldn’t need to make changes
• Plans > Shared Teams will go away immediately with the migration.
• @mention is the main immediate new function. There’s also value provided in the Team profile which will collate information about the team and associated work. Keep in mind this just the start of this new concept with plans to extend value. The critical work now is unifying team concepts as a foundation before building on it.

[Rhys Christian]

Hey @Jen Elam

Thank you for detailed feedback for Team controls/permissions, this will be valuable for the team.

"Is there any plan to allow deactivation of a team? "

Good question. There isn’t a soft-delete option for Team. However when a Team is deleted, that team will not be removed from the assigned issues. So that history of what teams worked on what issues will still be kept.

Deleted teams will not be listed in the ‘suggestions’ e.g when using JQL, to find the matching ID you’ll not be able to select the deleted team among the suggested team. You can query on deleted teams BUT you must know know the specific ID. The ID is harder to find for deleted teams without the suggestion or profile URL, but there is (not a great) workaround to show the ID in the url when hovering over a Team field value.

So this is fairly limited at launch, but the team will listen to feedback around this and may consider prioritising a more complete solution.

[Karin van Driel]

Hi @Rhys Christian ,

Thank you for your response. I totally understand the concern with cross site availability of the Teams, but this is not a concern for us. All our teams are in a single site, to enable us to report more easily and to fully make use of Advanced Roadmaps and dependency tracking. 

I have raised a ticket with the support team as per your suggestion. 

Thought I'd also share some thoughts on what could be useful functionality for Teams, in case it is useful for your Product Insights :) :

• Ability to group teams (aka Team of Teams concept)
• Ability to create lists of teams and controlling visibility at the list level, to ensure we can reduce the number of Teams showing in a dropdown - making this context driven, like we can do with options on a Custom field would be amazing. I think this would be useful for single site organisations that have lots of teams too, as well as be a way to address the cross site concerns. 
• Permissions to drive managing teams, specifically:
  • Creating teams
  • Deleting/Archiving teams
    • Restoring a team?
  • Updating capacity
  • Maintaining Team membership
    • Maybe a setting that indicates if users can join a team themselves, or if they need to be added/invited
• Ability to drive Team membership with user groups, so that team membership could be synched/controlled through Acccess Management tools, outside of Atlassian's products
  • I'd suggest the team should be created in the Atlassian products first, then linked to a user group for membership. Similar to adding people to a Project, it would be nice to either be able to do this at an individual and at a group basis.
• Ability to assign Team Member roles; someone's job title and their role within the team may not align, it would be nice to be able to define what role someone fulfills within the team, separate to their job title in the organisation as a whole.
  • This could perhaps follow the model we have in Projects, adding individuals or groups to a role
• Ability to manage Team Member's availability (calendar functionality)
• Ability to manage Team Member's competencies - knowing whether team members can code in a certain language for instance would help with the ability to assign work
• Ability to display a team's members (and their roles) in a Confluence page

Just my two pence for now :) 

Thanks!

[Rik de Valk]

Hi @Rhys Christian , 

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? 

This is all about autonomy and alignment. To allow for maximum autonomy it is obviously a good idea to allow all users to CRUD Teams. But as organisations or their Atlassian footprint grow, the need of more controls around the configurations grows. 

In organisations where Agile methodologies are used at scale, the Team assignment is a critical dimension in their management information. It will be used for capacity reporting and maybe even cost allocation. Having a certain level of data quality on this data is important in those cases. 

Secondly, the Team field is by its nature a shared field (the pick list options are available across projects). With high number of Teams, it becomes important that the Teams are recognisable. It will probably be wise to apply a naming convention. Otherwise it will become very chaotic very fast. 

Finally, larger organisations (or organisations with a mature scaled agile approach) likely have some other team-repository. In these cases it is desirable to synchronise the Teams in Jira with the 'golden source' for Teams in the organisation. This can either be done manually, or automatically; but in either scenario, it is undesirable that users can CRUD teams. 

----------------

The other requirements I listed in my comment are also mostly valuable in case of 'scaled agile environments'. 

For example: the ability to select multiple teams on an issue. This is an important requirement when users use Advanced Roadmaps where larger bodies of work are defined above the Epic. These issue types (Initiatives) typically require the involvement of multiple Teams. It would be awesome if Teams can filter on Initiatives where their team is selected, so that they get insight in the portfolio demand that requires their effort. 

And my Teams-of-Teams requirement also fits this context. In organisations with >100 teams, it will become valuable that a drill-down can be performed from Teams-of-Teams to Teams; in JQL queries, or in the Team select field. 

[Dianna DeCristo]

Can you please provide a link to the API if one is available to retrieve the members of each team? If one is not available, do you have a timeframe for when it will be?

[Alex van Vucht]

Could you please explain more about the gadgets your users miss and their use cases for them?

We keep our Jira configuration tightly controlled as we are a small team managing a Jira cloud environment of tens of thousands of users. Our users can have many teams working in a Jira project or even from a single board and have found Advanced Roadmaps Shared Teams to be an effective method to manage capacity at scale. There is widespread use of the Advanced Roadmaps product: users have similar access to create and manage plans and shared teams that they have for creating Atlassian cross-product teams.

Dashboard gadgets are popular not so much for their use on Jira dashboards, but for their use in Confluence pages through external gadget macros. There was extensive use of the Team field in all gadgets that aggregated data. The Jira Charts macro is similarly affected. Since migrating to cloud, Confluence users have not been able to use the Team field anymore in their reports.

[Tal Levinger]

Can we query the teams in JQL? ask if a user is a member of a team?

[Jen Elam]

@Rhys Christian Thanks for the feedback.  It's good to hear that deleting the team will leave the field value, but it sounds like there isn't an easy way to restore the team once it's deleted.  I'm assuming that even if you create the team again with the same name, it would have a different ID and the system would treat this as a new and different entity.  How would you recover from that?

We also use our custom Team field in widgets pretty extensively.  We wouldn't be able to fully switch to the new field without this.

It'd be nice to give admins some more control over teams - basic CRUD functions and the ability to surface teams in specific instances and even specific projects.

We’re working on some challenges with Enterprise which is the reason it is latest in the rollout. We’d be interested in your insight that may be relevant. The main challenge we’re looking at addressing relates to the fact that Atlassian Teams is a Global concept - so Teams become visible across sites with extended visibility/access. 

We're an Enterprise customer with about 15 different Jira instances that represent distinct companies.  Some of the instances have shared application links between them and some are completely separate instances.  They are all under a single org.  I'd love to share some of our use cases if you are interested in hearing more.

[Clyde Moseley]

It would be great to be able to add TEAM to at least notification schemes so members can be notified when their team is selected (assigned) on a ticket.  I have tried rigging something in automation to add a team mention as a comment when the team field is changed but I have not had any luck.

[Erki Tammik]

@Rhys Christian 
When will this be rolled out for Premium plan users?

[Rachael Williams]

@Rhys Christian - on your response to the "rollout" I'm seeing on Premium, you are correct that we don't have the teams unification yet.  We are just seeing that we have the "Team" menu now and Plans>Shared Teams appear to have been copied over from some point in time, but not sure what date this happened.  Now we were in a time period where the new feature is not turned on, and the old team feature exists and is still being used, so 1) users are confused where new teams should be created and 2) the list of teams copied over have grown to be different over the past few weeks and we are no longer reconciled.

Will another copy happen before the feature is released to premium users?

Do you have any target timeline?  In May you commented that it might be ~3 weeks away so I'm expecting we might be pretty close now?

[Edie Hovermale]

When is this change coming? We could really use this now. :-)

[Matt Kavanagh]

Makes a lot of sense - I've also found the fact that team exist in both areas of the software a bit confusing so this is good simplification.

Whilst on this topic of Shared Teams, can anyone shed any light as to what benefits arise from adding members into teams? Other than having a record of who-works-where, I'm assuming there are planning advantages but I can't see where?

[Erki Tammik]

Also, when this will be released for Jira Product Discovery?