Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,365,410
Community Members
 
Community Events
168
Community Groups

Constraints and best practices for Teams in Advanced Roadmaps

Edited

We've recently made the switch to Advanced Roadmaps. We were using a custom field for issue assignment to teams. We have switched to using the Team field in Advanced Roadmaps.

I have found a number of non-obvious constraints which I'll publish as a discussion. Firstly, I want to raise awareness of these issues for people transitioning to AR so they can set their user's expectations and, second, I'd like to hear from the community and collect more that I haven't hit yet. I hope to link to the Atlassian feature request/bug for each constraint to track them.

Note: This is for Cloud version of Jira Premium.

As a side note, if anyone else is moving from a custom field for issue assignment to teams to using the Team field, I have written up a procedure to do this programmatically. Let me know if there is interest and I'll publish it.

Before I list the constraints I just wanted to say that I'm loving Advanced Roadmaps. It's a great tool. The constraints below are intended to increase awareness and assist the community, they aren't intended to be a critique of the tool.

Here are the constraints I've found so far:

  • You cannot sort by Team in JQL. This is my most common use case as I provide lots of metrics to the wider organisation and each team expects their data grouped together. JSWCLOUD-20787 and JSWCLOUD-19957
  • The Team custom field can't be used in many Dashboard gadgets (e.g. pie chart gadget) JSWCLOUD-20787 and JSWCLOUD-19957
  • Team custom field can't be used as a swim lane in a Kanban board. (Workaround is to use Query-based swimlanes and write a query per team) JSWCLOUD-17580
  • Team custom field can be queried via JQL but cannot be queried in Basic Search JSWCLOUD-19187
  • When the Team field is queried via JQL it gets turned into the numeric Team ID. This can make it hard to maintain the filter when the Team isn't clear from the filter name. (The same goes for board quick filters) JSWCLOUD-19523 
  • When you associate a shared scrum Team to a plan, you need to configure the velocity and sprint duration in each plan even though the value is unlikely to be different across different plans. [Design choice by Atlassian: the intent is that velocity is unique per plan and not shared across plans. This effectively allows "guardrails" where you split a teams velocity.]
  • There is no easy way identify filters that are using the old custom field and need to be updated to using the Team custom field. JRACLOUD-77323 
  • There is no easy way identify boards that are displaying the old custom field and need to be updated to using the Team custom field. JRACLOUD-77323 
  • There is no easy way identify dashboards that are using the old custom field and need to be updated to using the Team custom field. JRACLOUD-77323 
  • A workaround is required to set a default value for Team in automation rules as Team is not a field you can directly choose from the drop down. This is an important constraint as a common use case is where one Team works out of one Project. In this use case you'll  want to default every new issue in that Project to that Team. You need to find the numeric value of the Team (e.g. what is auto-completed in a JQL query). Then you need to use the advanced script to set the value.
{
"fields": {
"Team":"29"
}
}
  • Subtasks cannot be assigned a Team. Subtasks inherit Team from the parent issue. The Team field should be removed from any subtask-related screen because it will say "None" even if the value is inherited from the parent issue and the value can't be set on the sub-task. JSWCLOUD-20638
  • While you can assign users to Teams as team members, you cannot track any other information e.g. Role or % allocation

I will try to keep this up to date with further issues I find and with feedback from the community.

2 comments

"When you associate a shared scrum Team to a plan, you need to configure the velocity and sprint duration in each plan even though the value is unlikely to be different across different plans."

 

Bump!  I was really expecting AR to calculate, or let me enter a formula such that it calculates the velocity based on data already existing in the system.  I mean we already do this on some of our dashboards, so why not provide it as a possibility.  Entering velocity for every Plan is just unsat....

Like Darrel Jackson likes this

Well, I get that calculating velocity for the team isn't straightforward so I wasn't expecting AR to do that. But I was only expecting to track velocity per team not per team per plan.

Like Aaron Gage likes this

Hey Darrel,

This list is a pretty comprehensive assessment of the known constraints when it comes to the Advanced Roadmaps Team concept. 

One slight nuance to one of your points: the swimlane for Teams is possible for Kanban boards in Company Managed Projects as they are defined with a query (though you'd need to rely on the suggested team). Indeed there's no way to swimlane via Team in Team-Managed projects.

The remaining points you make are accurate. I should note that there are major changes coming to the Advanced Roadmaps Team concept as we're working to unify different concepts of Teams. AR teams are going to be migrated into the Atlassian Teams concepts (i.e the concept in the People & teams dropdown). These teams a global entity so that the Team used in AR will be the same entity as used in other Atlassian tools.

There are a number of other major improvement on the way for Atlassian Teams before we migrate to them (such as JQL, issue assignment). There's still some time before this will happen so I can't offer a breakdown of all the capabilities that will be added, but it will continue to improve with a dedicated team looking after Atlassian Teams.

So some of the point you make are likely to change (e.g JQL using ID, basic search, automation etc. may be different). But as this concept will have a team dedicated to it, and it will be leveraged further across Atlassian products, we expect the concept of Teams to be like its own product with regular dedicated focus (rather than just a partial focus within Advanced Roadmaps). Unfortunately there's not a lot more detail I can offer about it at this time but more will be shared over time.

Out of curiosity, could you please lend more detail about your needs for "you cannot track any other information e.g. Role or % allocation". What use cases relate to this need and how would you leverage this info in your day-to-day? We're considering further enhancements to planning with teams / capacity in Advanced Roadmaps so your feedback on this would be appreciated. 

Kind regards,

Rhys | Advanced Roadmaps, Product Management

Like Aaron Gage likes this

...the swimlane for Teams is possible for Kanban boards in Company Managed Projects as they are defined with a query (though you'd need to rely on the suggested team)

Do you set "Base Swimlanes on = Queries" then write a query per Team? (e.g. "Team = 28"). This does work but is quite fiddly as a) you need to look up the team ID b) you have to write a query per Team.

In the board I use to manage our top-level initiatives we'd have ~10-15 teams out of a possible 36 teams that would "own" an issue at any given time. In practice any team can "own" a top-level initiative so I'd need to write 36 queries. I'd also need to update that board every time I on-board a team. As a result I won't be using this workaround.

Out of curiosity, could you please lend more detail about your needs for "you cannot track any other information e.g. Role or % allocation". What use cases relate to this need and how would you leverage this info in your day-to-day?

Sure. One thing our organisation is struggling with is how to track virtual team membership. It's virtual so we can't use our org chart.

We'd like to have fully autonomous teams however in our transition to agile methods we have some resource sharing between teams. That may continue to be common place depending on how we treat for scarce domain expertise. We could track that in a spreadsheet or Confluence table but I'd rather track that in Jira as it's closer to where the work happens. It would be good to see what Teams someone is in and what the % allocation is (if defined). Another use case is a resource has some operational role that takes a % of their time so only some of their time is available to the team. Tracking this is useful as it allows us to calculate burn rates per team for funding (i.e. sum(daily rate * % allocation) * sprint length = $ cost per sprint). I don't need Jira to calculate the %, just track it manually.

With regards to Role, it would be more transparent for people outside the team if the Role for each team member is tracked. We typically have a team lead, a business analyst a solution architects and a test lead as standard roles and it would be good for people outside the team to know who is in what role so they can better engage with the team.

edit: And thank you for your very detailed response. If there are any specific support tickets/R&D tickets that I can reference above please let me know.

Like # people like this

Hey Darrel, Thanks for following up. 

Indeed the way that swimlane queries need to be defined with ID is not ideal, especially when dealing with the scale you have and in addition to the shared initiative use case. One thing that makes it a bit (as opposed to looking up the IDs) is to rely on the 'suggested teams' which can be searched by typing the name. Clicking the selection will then set the ID for that team.

 Screen Shot 2021-08-26 at 2.44.44 pm.png

I recognise this is still very finicky and relies on typing the queries individually. This should be an area that will improve as we work to unify with Atlassian Teams and continue to improve the capabilities of Atlassian Teams.

 

I appreciate the additional details you've provided for needs around role and allocation. This will be pertinent for initiatives we intend for our future roadmap around more detailed resource planning. This area is currently part of our more longer-term plans, and dependent on us first unifying our concept of Teams, but your insights will be helpful as we envision it.

 

Regarding tickets, I understand there are some internal support colleagues that are consolidating relevant requests to follow.

Kind regards,

Rhys

Like Anita Liu likes this

That's good to know, thanks.

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events