nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Question around whether multiple Jira Projects or 1 Jira Project is better for a team's work

Darren_3xxj1j

I've always tended to follow the principle: "1 team, 1 backlog, 1 board, 1 Jira Project"

And so teams would put their 'big work items' as Epics, broken down into smaller deliverables (Jira Issues).

It _feels_ like I ought to be using multiple Jira Projects somehow to add an extra layer of hierarchy and to make things a little more 'contained'..
I.e.,
One Scrum/Kanban Board that points to...
...multiple Jira Projects (that will eventually get 'done' and archived), that are broken down into...
...multiple Epics (and then their Issues)

However, I imagine the admin overhead would be a bit burdensome:
* create a Project
* update the original Scrum/Kanban Board's Filter to point to the new Project
and then when archiving the project once it's done and delivered:
* delete/archive the relevant Project(s)
* update the original Scrum/Kanban Board's Filter to remove the Project(s) from it

That all seems a bit cumbersome which leads me to sticking with my '1 team, 1 backlog, 1 board, 1 Jira Project' principle.

Has anyone found a compelling reason to use multiple Jira Projects to organise the work, rather than just 1 Jira Project with a bunch of Epics? And if so, how have they found it from an admin perspective?

Trying to tap into others' experiences here before I take a leap...

Accepted answers

Matt Parks

At my company, we have a couple different uses for Projects. They can either be Project Manager-led projects like a company-wide upgrade of servers to Windows 2022, or they could be specific to a particular product that we offer.

For most of the products, we use a shared configuration, so the issue types, workflows, and screens are consistent across the projects, which allows us to have the same team working on multiple products (i.e. Jira projects) with a minimum of administration. If a team is working on a particular issue, they update the Team field accordingly. Because of this, we make the Team field required (sometimes at Create, sometimes to move out of the initial status, if there are multiple teams who could work on a particular product).

All of the boards are populating based off of the Team field per the standard query below:

(project = xxxx AND team = 12 AND issuetype != epic OR team = 12) AND issuetype not in (epic, "Work Request") OR issueFunction in epicsof("team = 12") AND status != Done ORDER BY Rank ASC

The project isn't particularly important, it just allows the board to be associated with a project, but it will pull in work regardless of which Jira project that work is under.

So, if a team is working on multiple projects, or a new project spins up, the board automatically pulls in that work dynamically, as long as their team is in the Team field.

This only works well if each issuetype shares the same workflow regardless of what project it is under. Otherwise the status mapping gets a little crazy.

The main benefit of this is that it is very easy to determine what areas (e.g. projects) the team will be working on as well as what they have been working on, since you can group everything by project. It's also very helpful if your organization gets any kind of R&D tax credits or IT Capital Expenditure credits, as it's very easy to group all of the work.

If it makes a difference, I'm using Data Center, not Cloud, so I don't know if all of these options are available in the non-Premium version of Cloud.

Mary from Planyway

Hi @Darren

The strategy of "1 team, 1 backlog, 1 board, 1 Jira Project" you've been following is indeed a popular and effective approach for many agile teams, especially when simplicity, focus, and team cohesion are priorities. It facilitates clear communication, easier backlog grooming, and straightforward sprint planning. However, as organizations scale or diversify in the projects they undertake, the idea of using multiple Jira Projects can become appealing for several reasons, despite the administrative overhead you've correctly identified.

Project Specific Workflows: Different projects may require unique workflows that reflect distinct processes, stages, or approvals. Multiple Jira Projects allow for customization that a single project structure might struggle to accommodate without becoming overly complex. Thanks to some third-party apps like Planyway you can have a visual project portfolio to streamline your workflow.
Security and Permissions: When working with external stakeholders or on sensitive projects, it's crucial to manage access meticulously. Separate projects can have their own permission schemes, ensuring that team members and stakeholders only have access to relevant information.
Focused Reporting and Metrics: For organizations that require detailed tracking and reporting per project (for billing, performance assessment, or compliance purposes), having separate projects can simplify these tasks.
Scaling Agile Practices: As teams and portfolios grow, a single Jira Project might become too cluttered, making it hard to maintain a clear overview of all ongoing work. Multiple projects can help in organizing work more efficiently, aligning with scaled agile frameworks like SAFe, where there's a need to manage work at team, program, and portfolio levels.

Managing the Administrative Overhead

Indeed, managing multiple Jira Projects introduces an administrative overhead. However, there are ways to streamline this process:

Template Projects: Use template projects with predefined workflows, permission schemes, and issue types to reduce setup time for new projects.
Automation: Leverage Jira’s automation features to manage tasks such as updating board filters or notifying admins when a project needs archiving.
Board Configuration: Use advanced JQL (Jira Query Language) in board filters to automatically include or exclude projects based on certain criteria, reducing the need for manual updates.
Bulk Changes and Scripts: For repetitive tasks, like archiving or updating multiple issues, use bulk change features or scripting (via ScriptRunner or Jira automation) to save time.

All comments

Matt Parks

All of the boards are populating based off of the Team field per the standard query below:

(project = xxxx AND team = 12 AND issuetype != epic OR team = 12) AND issuetype not in (epic, "Work Request") OR issueFunction in epicsof("team = 12") AND status != Done ORDER BY Rank ASC

The project isn't particularly important, it just allows the board to be associated with a project, but it will pull in work regardless of which Jira project that work is under.

So, if a team is working on multiple projects, or a new project spins up, the board automatically pulls in that work dynamically, as long as their team is in the Team field.

This only works well if each issuetype shares the same workflow regardless of what project it is under. Otherwise the status mapping gets a little crazy.

If it makes a difference, I'm using Data Center, not Cloud, so I don't know if all of these options are available in the non-Premium version of Cloud.

Mary from Planyway

Hi @Darren

Project Specific Workflows: Different projects may require unique workflows that reflect distinct processes, stages, or approvals. Multiple Jira Projects allow for customization that a single project structure might struggle to accommodate without becoming overly complex. Thanks to some third-party apps like Planyway you can have a visual project portfolio to streamline your workflow.
Security and Permissions: When working with external stakeholders or on sensitive projects, it's crucial to manage access meticulously. Separate projects can have their own permission schemes, ensuring that team members and stakeholders only have access to relevant information.
Focused Reporting and Metrics: For organizations that require detailed tracking and reporting per project (for billing, performance assessment, or compliance purposes), having separate projects can simplify these tasks.
Scaling Agile Practices: As teams and portfolios grow, a single Jira Project might become too cluttered, making it hard to maintain a clear overview of all ongoing work. Multiple projects can help in organizing work more efficiently, aligning with scaled agile frameworks like SAFe, where there's a need to manage work at team, program, and portfolio levels.

Managing the Administrative Overhead

Indeed, managing multiple Jira Projects introduces an administrative overhead. However, there are ways to streamline this process:

Template Projects: Use template projects with predefined workflows, permission schemes, and issue types to reduce setup time for new projects.
Automation: Leverage Jira’s automation features to manage tasks such as updating board filters or notifying admins when a project needs archiving.
Board Configuration: Use advanced JQL (Jira Query Language) in board filters to automatically include or exclude projects based on certain criteria, reducing the need for manual updates.
Bulk Changes and Scripts: For repetitive tasks, like archiving or updating multiple issues, use bulk change features or scripting (via ScriptRunner or Jira automation) to save time.

Darren_3xxj1j

Thanks @Mary from Planyway

Darren_3xxj1j

Thanks @Matt Parks

Darren_3xxj1j

Quick one, please, @Mary from Planyway

(and I confess to asking you this before doing my own research / browsing the documentation on the subject... I wanted to ask you before I forget...)

"Template Projects" - is this provided with 'out of the box' Jira? Or is it something custom-built using things like 3rd party apps (like Bulk Clone Professional), Automation, and/or ScriptRunner?

In summary, can you give a high-level overview of the steps required to create and then use Template Projects?

Thanks in advance

Mary from Planyway

Atlassian's Jira does not offer a direct, out-of-the-box feature explicitly named "Template Projects" in the way you might expect, where you could simply click a button to create a new project from a template. However, Jira does offer ways to achieve similar functionality through a combination of project creation based on shared configurations and the use of schemes (like Workflow Schemes, Issue Type Schemes, etc.) to standardize settings across projects.

Additionally, Jira Cloud introduced project archetypes, which act like templates when you're creating a new project, allowing you to start with a setup that's intended for software development, project management, or task tracking, for example.

For more advanced template-like functionality, such as duplicating projects with specific issues or configurations, third-party apps from the Atlassian Marketplace, automation rules, or custom scripting via apps like ScriptRunner are often used.

Using Third-Party Apps or Custom Solutions:

Explore the Atlassian Marketplace: Look for apps like "Project Templates for Jira," "Deep Clone for Jira," or "Bulk Clone Professional" that offer cloning or template features.
Use Automation: For Cloud users, leverage Jira's built-in automation rules to automate repetitive tasks or setup processes for new projects based on specific triggers.
ScriptRunner: If you need more custom functionality, such as scripting complex workflows or automations, ScriptRunner can be used to script these processes, including the creation of projects based on a template model.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud