When should I create separate projects in JIRA

Question

I've been using JIRA for few months -we are following traditional development methods (no agile/scrum). One of the things that I cannot decide, is when should we create separate projects in JIRA, and when should we add issues to the current projects and not creating new projects.

The nature of the projects we work on is something like the following:

• Mobile App development (3 months project)
• Gamification App (3 months project)
• Extend mobile App features (few months later after going live - one month)
• Adding functionalities to the current CRM platform (some of them 2 days, other 2 weeks developments)
• Another Gamification App for the same client (3 months)
• Support for all live projects and bugs fixing (on going).

Currently, each client has only one project in JIRA, and all, let's say the client gamification Apps, and mobile Apps, are added under this project. So tasks are shuffled between the many different products under one project. In addition, there is support tasks, and another product extension to add more functionalities which might take weeks to develop. It is hard to see each product separately as standalone project. It is even hard to see each development cycle for the same product separately (I'm here referring to adding extra functions to the same project after it goes live, it is more like new business with new budget). Hence, it is hard to find all related tasks to this App and provide how much time spent on it.

Another issue is, all these on going support tasks, are added to each project per client. Say we have 4 clients, each support task is added to the related client project. However, these bugs belong to sometimes totally different platforms, Apps ... etc.

My question, should we create a separate JIRA project for each of the above projects?

How about bugs fixing and support. Should we add them to their product projects (i.e., bug in mobile App, is added as a task to the mobile App project)

Although I feel this should be the way, there is a concern within the team (since we have numerous small projects), that the number of JIRA projects will grow rapidly, such that we will not be able to find the projects easily in the list (so we do not want to run from tasks confusion, to projects confusion). That is, it is important to us as well to categorize our work per client.

So in a nutshell, should JIRA projects be created per client or per product? If per product, is there a way to display reports on aggregated projects per client?

Answer 1

Go back to the basics and pretend you don't have JIRA. How would you organize the projects?

What I would do is create a portfolio folder for each client and then their projects would be within that folder.

Maybe your company really does have a lot of small projects, you shouldn't be nervous about modeling JIRA based on the reality of the situation.

You can use filters in JIRA to create a board that will show tasks/stories/tickets across projects.

For example, we have a team that works on 3 different projects. All of those project tasks appear on 1 board.

Answer 2

A project in Jira is not equivalent to a "Project" in real life. Projects in Jira are organizational containers that store different Issue Types, Workflows, Screens, Custom Fields, Issues, etc.

Typically most people should define a Jira Project for each Team of major ongoing project or "silo" they have. For example if you have a Development Team and an Operation Team, you would make 2 projects, one called "Development" [DEV] and one called "Operations" [OPS]. If you want to track all issues related to Help Desk tickets for instance, you'd create a "Help Desk" [HELP] project.

If you always support a large website, you COULD create a project just for that, but if the type of work associated with that utilizes the same people on a development team for instance, you're much better off making a project for your team and not the website. You can instead use Components and create one under your DEV project for your website. You could have issue types for bug report, etc. There's a lot of ways to set up things but the established design models do make sense once you have to administer them day in and day out.

I also like to create a separate one for "Change Control" [CR] as there are often really specific people and workflows involved with those.

You should NOT create a Jira Project for every small project you are managing. That would create an administrative nightmare and in fact it's why Jira recently came out with "Next-Gen Projects" if you want to read up on those more.

Answer 3

Generally, there's no right or wrong way in Jira. It depends on your organizational structure as well what kind of Jira project you are using - there are some different feature sets between "classic" or "company-managed" projects and "next-gen" or "team-managed" projects in Jira, especially around board configuration and queries and it's unclear if there will be total feature parity between these configurations.

If you're using the team-managed Jira projects, you (as of August 2021) cannot create multiple boards per project or edit the board query filter to pull in issues from across projects. These limitations may drive you to either opting away from team-managed projects or structuring your projects in a different way.

For company-managed projects, there are different ways to structure them.

If you're a product-centric organization, I'd suggest one Jira project per product and then using boards (and the backlog that comes with a board) for each team. You can also create higher level boards, such as boards that are filtered to show Epics or only certain types of work to give visibility into specific types of issues.

If your organization operated in project-mode, then I'd probably lean more toward one Jira project per project (or program, where a program is a set of related projects that are managed together). You can then create different boards to give a cross-project view across the program or views into specific projects as needed.

If you do a lot of smaller projects for different clients, then I can see it being feasible to create projects for each client and using boards and labels to divide up the work into different projects or products.

Beyond projects, you'd have to consider how you'd use the Component and Label fields that Jira provides. The project along with the Component and Label fields are the best ways to be able to segment the issues into different categories or buckets, such as by project, deliverable, customer, source, or level of visibility and create filters and views over the related issues.

My recommendation would be to step away from Jira and look at the products you are producing, the projects you are running, and how teams are allocated to projects and products. This will give you good insights into how to structure the work in Jira. If you do a good job with labels and components, you'll be able to bulk move issues to new projects in the future if you need to.