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; } } }

Does your team use multiple projects or multiple epics?

Kenan Carames

Hey everyone! I was just curious about how others are using Jira... I am a part of a large organization so my team has been customizing Jira within our Project (the Jira term). To manage our different projects (our term), we have been using Epics to keep track of these. In Jira, Epics have become our version of reporting and managing projects and business goals.

My "question" is how are other teams using Jira? Do each of your real life projects get a separate Project in Jira or are you managing your projects through Epics? Because of the way it is set up in our organization, it never occurred to me until now to actually create a Jira Project for each of our projects... Have you found benefits to either approach?

Comments

Sayed Bares [ServiceRocket]

Hi Kenan,

We prefer using projects since it is much easier for reporting and obviously a better way to organize and manage the stakeholders.

I would say one of the downside of using a single project would be scalability. If your epics or issues grows on that single project, you might experience performance issues when searching through JQL.

Rick Olson

We too, have been managing all our business projects in a single Jira project.

As we have been supporting our existing products using Jira, we started out using an epic to represent each project. As we struggled with only having the parent and sub-tasks levels available to us, we added an Initiative issue type as a parent to the epics. Thus, business project = Initiative. With most of scrum teams being interdependent, each team has their own epic that contains the work for their team. Each team having an epic is important because we do epic-level estimates to size the entire business project (a.k.a. Initiative) before getting approval to build out the backlog of stories across the teams). Advanced Roadmaps supports the addition of the Initiative issue type for sprint planning and capacity planning, and Jira supports the Initiative using the parent link of the epic.

That said, as we are taking on a very large, new business program, we create a separate Jira project for each business project. Thus, business project = Jira project. Again, because of our interdependency of all of our scrum teams, we may find that we move stories from each of the Jira projects (which are business based) to Jira projects that represent the scrum teams.

Dan Enslen

We use both. As an example, each of the engineering teams has their own project for the items they work on and run their own sprints. There is a main project that contains all of the separate projects working on it. It's a Scrum of Scrums. All of the individual team sprints are shown on the board for the main project.

unknown

Hi @Kenan Carames ,
We usually do in my company to have a Jira for each big team, this way each team can be managed with epics, and we can see the workload of each one of us.
The heads have access to be able to see what is being worked on, the workloads of the teams, with their stakeholders, and the evolution of the projects.

Andreas Haaken (APTIS)

Hi @Kenan Carames ,

we use Issues( Epics) as projects from the beginning in 2014. The reason was very simple:

as long as you use Issues as projects, you benefit from issues capabilities, as there are:

- workflows : projects have lifecycles (JIRA-Projects (JPs) don´t)

- automations: you can use a lot of automated stuff as in issues that just works for your issues as projects and won´t be available for JPs

- communications: you may use issues as communication base, which is a lot more difficult on JPs, example: emails into comments and threaded by issue comments

- flexibility: issues as projects can live in their own context (if you want), that can be shared with many projects of that kind (like for a customer)

explanations:

JPs are intended to be projects of a large scale or long running product. That´s why they missed many things that are relevant for multi project management. You won´t see that if you are in a long running project, where it works fine.

But after some time Atlassian adds more and more features that compensate the missing parts. But in my opinion they are still far away from the needs with the JPs. Anyway with the help of some tools and policies multi PM works just fine.

hope that helps

Welcome!

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

Quick Links

Find more posts tagged with

server

project

hierarchy

advanced-roadmaps

epic

project-management