Project admins: How do you find all fields used in your team managed project?

[Saskia van der Peet]

Hey Project Admins 👋

I'm a Product Manager at Atlassian, and eager to hear your insights.

What is your process for finding out which fields are used within your team-managed projects?

Edit: Updated for clarity.

[Haddon Fisher]

Hey Saskia van der Peet,

There's a bunch of different use-cases in there depending on how you read your question, but the short answer for all of them is "painfully" 😂. Generally I do this one of two ways, depending on whether I'm looking at a single project or "holistically":

• If I am analyzing a team-managed project for a company-managed project migration, I usually pull up each request type and go through field by field. Ultimately I need to do this anyway to swap them for company-managed replacements, so it's not entirely wasted time.
• The other common use-case is I or someone else is working on something, and we hit a problem created by having 7 different "Story Points" fields or some similar nonsense*. I then will...
  1. Pull up fields API endpoint in my browser ('JSON Formatter' chrome extension FTW)
  2. Find the team-managed projects hosting the duplicate fields
  3. Go into each project and rename the field with a suffix containing the project key (i.e. `Story Points (XYX)`).

As other people have already called out, the best solution to this (and the host of other issues TMP's create) is to not have them.

* - This is often "just" a usability problem i.e. "I need this A4J rule to update the 'story points' field, but I don't know which one is the right one" but there are several legitimate (and painful) bugs here as well.

[Symantha Gates]

Agree with the "painfully" comment. ;-)

[Saskia van der Peet]

Thank you so much for your insight Haddon, I really appreciate it! 

[Symantha Gates]

In the Current State, Atlassian's approach to fields can create alot of work for the JIRA admin. Surprisingly, I find this is a part of the system a bit unstructured. The custom fields or even the fields which are presented at all - on project or team boards - are relatively freeform. This may seem like it is advantageous in a 'DIY' or 'we manage our own stuff' project/board approach.

However, in a more enterprise setting with multiple teams working together, could Atlassian provide a kind of governance method for fields to require or enforce certain fields across all boards? This would really help with cross functional reporting. For example, we recently discovered that nearly every of our boards (50+) were using different date fields which had been modified - Due date, Expected Due Date, Due Date, Target Completion date - while the default JIRA value is "Due". Because of the variety and the fact that any project could change their fields, our reporting was essentially unreliable. To get fields to a common pattern took a couple of months of outreach, communication, bulk uploads, & bulk deletions to normalize the fields across all boards. To figure out which fields were used we had to do custom exports from all boards which created alot of manual work. Too bad there was no way to compare project A to project B, for example, and quickly find the fields that were in common and the ones which were not.

Would Atlassian consider an offering where there is a base set of fields which all boards receive and then a variable set of fields on top of that which can be customized? Or perhaps create a pool of standards and each board is assigned to a pool and receives mandatory fields from that pool? It seems odd that there is no metadata which is configurable or maybe that would be a great feature to add ?

[Saskia van der Peet]

Hey Symantha, 

Thank you so much for sharing this! I totally hear you, and will share your experience back with the team :) 

[Kim-Stacey Kidder]

@Saskia van der Peet I use a REST api and the Admin custom fields page for reference (for custom fields used within the Team-managed projects). Clunky, but it works.

[Saskia van der Peet]

Thanks so much Kim-Stacey! 

[LAL]

Are team-managed projects still a thing? 

Few years ago when they came out i thought they were the next big thing, but then Atlassian suddenly but them on hold.

We were originally supposed to use team-managed projects (called next gen back then), but then the support got seemingly dropped.

Interesting to see if they'll be viable option in coming years.

[Saskia van der Peet]

Hey LAL 👋

Thank you so much for this feedback. Yep, they are indeed still a thing :) 

[Joseph Chung Yin]

@Saskia van der Peet -

It is my understanding that for Team Managed Projects - "Fields in team-managed projects are contained within the project itself.' (still a major drawback).  This is why in our organization, we are using "Company Managed Project" primary and moving away from the "Team Managed" route.

Team managed project is a great idea, but it is extremely difficult implement common standards - thus one may end up a wild/wild west situation although it gives the ability to each project admin to configure the project to his/her needs.  This is always a fine line to walk on within a global organization.  Most importantly, the fields within a project is currently not shareable with other projects.  Although, team managed project can use fields from company-managed projects in your team-managed project, but the fields must be configured with Global context.

Hope this helps and it is my opinion.

Best, Joseph Chung Yin

[Karine VANEL]

Hi @Saskia van der Peet ,
Like @Joseph Chung Yin we limit the creation of Team managed project. They represent à small part of the spaces. All news fields created in Team managed project complicate the management ans user support of JQL filters, widgets and export. We give recommendations and carry out cleaning regularly by creating generic fields with context global. We compare the fields available in JQL and in admin page. This lacks tools for the administrator

[Elizabeth Nixon]

I thoroughly agree on the challenge with implementing common standards across multiple team-managed projects. I think the ability to create a template that can be used across multiple team-managed projects would be helpful. I know this brings up the question of 'why not just use company-managed projects?' but we want to use team-managed for the engineering teams and then I bring them all into one board in a company-managed project.

[Saskia van der Peet]

Thank you Joseph, Karine, and Elizabeth for your helpful insights, and thank you for sharing your thoughts towards Team Managed Projects, it is really helpful for us to hear!

[Nicolas Grossi]

@Saskia van der Peet Nice te meet you!. Here you have an option to do it: https://community.atlassian.com/t5/App-Central/Custom-Fields-in-Team-Managed-and-Company-Managed-Projects-Jira/ba-p/2437675.

Nicolas

[Saskia van der Peet]

Hey Nicolas!

Thank you so much for your help - I'm actually a PM at Atlassian, and curious to learn more about how project admins determine which fields are used within their team managed projects. Keen to hear your insights too - 

Many thanks again, 

Saskia