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? 

[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/

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