How to Best Group Work Items By Project Across Spaces

[Matthew Rumph]

In our organization each team has their own space. In their space, they will work on stories and bugs that can span across multiple projects.

Other teams may also be working on stories related to the same project however, they'll working on them in their own, separate, Space. 

My question is what is the best way to create a filter or view to organize work by a "project" that could include all work types, teams, and spaces. 

Custom fields are too manual as the list of projects can be 100s and fluctuate (additionally, I'd like to track some metadata on the project itself). Creating a work type above Epic in the hierarchy worked for a while but required rigorous upkeep on ensuring every story had a parent Epic and every Epic had a parent Project work type. 

I see there is something call Atlassian Home Projects. However, that feature seems lacking in functionality and can only link at the Epic hierarchy level which excludes a lot of our work.

Thanks in advance for suggestions!

[John Funk]

Hi Matthew - Welcome to the Atlassian Community!

I suppose the simplest way to start would be to create a new Board that uses a filter that would include all of the work items you want to see that are related. You will need to have something about the work item so it can tell it goes with the other work items - maybe create a Component in each Space for each project name. 

[John Funk]

@Matthew Rumph  - Have you tried this? 

[Matthew Rumph]

The problem I'm facing is more related to how to maintain something like Component in each space. It needs to be consistent across all spaces in Jira and ideally centrally managed so I'm not adding a new component to 30+ spaces every time a new project is approved.

[John Funk]

You could use a label then - it is across all Spaces. 

[Trudy Claspill]

Do you leverage the Release/Version features of Jira? Do you leverage the Plans feature of Jira?

With regard to the solution suggested by @Sharad Dadarao Chate rather than a Text field I would suggest a Selection List field. The options available in the Selection List would be managed by Jira Admins. With a Selection List field you can mark options as disabled, so when projects are sunset or cancelled you can prevent that value from being used in any new work items.

If you use both Company-managed and Team-managed spaces the field must be created with a single default Global context to support use in both types of projects.

For future reference, an alternate approach could've been to organize the Jira spaces to each be a container for all the work of a "project". Then you could leverage the Team concept to identify the Team responsible for each work item. And each Team could have boards that filter for the work items allocated to their Team.

https://support.atlassian.com/platform-experiences/docs/using-atlassian-teams-in-jira-projects/

[Matthew Rumph]

A custom selection list field is likely the best solution. Managing a large list of options in the custom field is not friendly but might be our best approach.

[Trudy Claspill]

You could consider a Cascading Select list where you can have 2 levels of selections. Rather than having one selection list of 100's of projects you can create a first level grouping and split the projects into those groups at the second level. That would improve the load time for the field also.

You mentioned in one of your other replies wanting to automate setting the field rather than having the user manually set it.

Is there any data that is required to be entered in all item types by all teams that could be used to automatically determine the project to which the work belongs?

[Tenille _ Easy Agile]

Hi @Matthew Rumph 

Tenille here from Easy Agile.

Trudy’s suggestion of a managed selection list is a reasonable way to keep some consistency and governance inside Jira. Where you might start to feel the limits of that approach is when your goal is to map dependencies or track progress across multiple teams. That is usually the point where purpose-built apps come into the picture. 

If cross-team planning, dependency management, and tracking are a need that has driven your question, Easy Agile Programs is designed to bring a program of work into a shared view. If the need is more about communicating a cross-team view of work and timing, Easy Agile Roadmaps focuses on that use case. Happy to help with questions on either option if it is useful down the track.

[Mary from Planyway]

@Matthew Rumph 

Custom fields got messy fast, and enforcing hierarchy rules (Epic → Project layer) require way too much manual policing.

A few things we learned:

Jira doesn’t really have a native concept of a “cross-team project”

Teams can work on the same real-world project but store issues across different spaces, and Jira treats them as completely separate unless you manually create the linkage. Home Projects looked promising at first, but the limitation to the Epic level is often a deal-breaker.

Experiment with Planyway for Jira that can actually make sense of all that work.

It lets us:

• pull issues from multiple spaces into one view,

• group issues (epics, tasks, stories, bugs and subtasks) by users, spaces, epics, teams, components, anything really on the timeline view,

• save views for each project so stakeholders have a single link to check status.

The nice part is you don’t need to reorganize your Jira structure. Teams keep working where they work; you just get a proper cross-team roadmap on top of it.

If you want a consolidated “show me everything related to this project no matter where it lives” view, this ended up being the most sustainable approach for us.

[Sharad Dadarao Chate]

@Matthew Rumph Hi

The best approach is to use a single shared project identifier (text-based custom field) and populate it using automation, not manual selection or hierarchy.
This allows you to create JQL filters that show all work across teams, spaces, and issue types, while keeping project metadata separate and avoiding heavy upkeep.

[Matthew Rumph]

I like the concept of leveraging automation to accomplish this. Any ideas on what a trigger for the automation might look like? I can't get around the issue that at some point the end-user needs to manually notate which project the work item belongs too. 

Eg, work item created in a team space during sprint planning. The user will need to notate which project this will be part of. At this point they can select a project from drop-down. A free form text field will likely lead to too much variability in project names making queries/reports difficult.