Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Darren
Contributor
March 25, 2024

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

2 answers

2 accepted

2 votes
Answer accepted
Mary from Planyway
Atlassian Partner
March 25, 2024

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. 

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

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

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

  4. 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
Contributor
March 28, 2024
Like Mary from Planyway likes this
Darren
Contributor
March 28, 2024

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 Partner
March 31, 2024

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:

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

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

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

1 vote
Answer accepted
Matt Parks
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 25, 2024

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.

Darren
Contributor
March 28, 2024

Thanks @Matt Parks 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
TAGS
AUG Leaders

Atlassian Community Events