Pros and Cons of running multiple non dependent delivery projects under one Jira project

[Marija Robe]

Dear all, 

I need your advice on what is the best approach or what are the pros and cons in having 5-6 non depended, with different delivery teams projects under one Jira project.

I am new to Jira and I have to propose the best solution to a customer in the way of working when comes to development management.
From my understanding, there are two options:
1. I am in favor of this: in order to have a better overview of the development, especially when using work packages, themes, epics it's better to create separate Jira projects for each delivery project. or
2. The customer is in favor of this: have all the development stories(issues) together on the same board and use specific naming conventions in the description to filter out the relevant to each project while working. 

I don't see cons when comes to managing multiple projects if we go with the first option.  However, I can see why the second option might be the wrong one, as it can be prone to human error. First, because the same project board will be used by multiple teams that don't necessarily communicate with each other and we have to rely on personal tidiness when using the naming convention - if not, issues might be easily missed.

Can you help me understand what would be the best approach so I can support the next decision with more arguments?

Thanks for your time, 

Maria

[Mark Segall · Accepted solution]

Hi @Marija Robe and welcome to the community:

My experience is that it's best practice to have projects unique to the team in this situation. You can take advantage of reports and teams have less noise to contend with.  To solve for your customer's needs, you could create cross-functional boards/dashboards to aggregate all of the data in a single place.

[Marija Robe]

Thank you Mark for your welcome and for the good advice. 

I have a call with the customer to discuss this topic and hopefully, they will agree with the approach I propose and you also agree with it as well.

[Dana Weinbaum]

I would love to revisit this question and get deeper into the pros and cons of each option, as I used to work for a company who changed the composition of projects more than once.

If I have a single product/platform with several use cases - what are the pros and cons of each option?

Does it matter if each use case has its own dev+PM team or there's no alignment between dev teams and use cases?

What about more general things like documentation - should that sit as tasks/user stories in each project or as another project (in case of multiple projects)? 

If I understood the former answer, the main pro of multiple projects is removing the need to add a single label (with the name of the project) for filtering. Are there other, perhaps more meaningful pros in terms of boards, structures, etc?

Anyone can give feedback from their experience working on each of the models and roadblocks they came across?

Thanks

[Joseph Hansbrough]

Hi @Dana Weinbaum

I agree with Mark that in my experience, having separate projects has become the most clear path forward. First, I'll respond to your questions. I'll then explain why I think the separate project approach is the best option, knowing that you could approach it in a single project with similar results theoretically, but to your point, it would be in light of the potential for greater human error. 

If I have a single product/platform with several use cases - what are the pros and cons of each option?

Advantages of Separate Project approach 

1. Organization of tasks - simply put, your backlog can be more organized and reduced with separate projects and Sprint boards. Its worth noting that Scrum Sprint Boards in Company-managed projects can contain multiple projects in the same Sprint Board to, so having different projects does not prevent running sprints for the product as a whole.
2. Security roles and permissions - similarly, if there is a different dev + PM team, perhaps they would require varying levels of access to certain tasks that pertain to them. Having it assigned per project reduces the number of roles to create and establishes the project team in their proposed structure (e.g. if a PM has tasks that his team may not be involved in but contains some level of confidentiality (i.e. interview candidate), he can create a task for it without other team members being able to access given assigned permissions)
3. Clarity for project users - there is more clarity in the project priorities and timeline when presented in a project-specific board or manner. This could also help in the event that there are devs or PMs on multiple projects, as they can differentiate one versus the others.
4. Reporting and issue filtering - With a single project, the sprint reports and other dashboard views can showcase the trends and insights for a specific project. This filtering also allows you to show as many projects on a report and dashboard as you want also, so in essence, if the client wants to see everything in one place, they still can in the issue view.

Advantages of Single Project Approach

1. No confusion over where to create a ticket - having one project is a good way to maintain a clear call to reporting issues with all users knowing to create their ticket in the one project
2. Labeling discipline - by having things labeled rather than separated by project, it can instill a discipline for labeling things each time which enables more filtering points. However, that is not truly an advantage because of the robust filtering options available that can span multiple projects. 

Winner: Separate Projects 

Does it matter if each use case has its own dev+PM team or there's no alignment between dev teams and use cases?

I think that the fact that each use case has its own dev + PM team is a major consideration for why it makes sense to separate the projects out. The teams can operate within their own space while not being prevented from viewing the other projects' statuses.

What about more general things like documentation - should that sit as tasks/user stories in each project or as another project (in case of multiple projects)? 

In this case, I would suggest a couple of considerations. I have approached it in two ways before - keeping documentation in one project versus multiple projects containing documentation and being labeled. Either can work OK. However, the best approach in my opinion would be to have them maintain documentation in the appropriate project, and then consider storing the documentation in a separate repository, such as Confluence or SharePoint where the documentation can all live. Confluence would be a separate service to subscribe to, but it has cross functionality with Jira, so it may be ideal. 

Additional thoughts when running separate Jira projects

- Having a Jira project specific to a singular project helps to both organize and reduce the backlog for each project, so when you go to plan a sprint, for instance, you can know that the issues you are looking at are tied to that specific project. 

- You could use labels or even Components as mentioned for further filtering, but if the issues are specific to a project and tracked in its own project, it would offer clarity of scope, and allow you to report on the data and scope directly, at least in an easier manner, in my experience

 - The administration and configuration of each Jira project could be tailored for the team and project it is dealing with. Not knowing the nature of your products or projects, say there is a project that contains PII or information that specific users should not be able to access given confidentiality considerations. You could create security roles that accounts for this, but with a different dev team on each project, and likely a variety of roles and permissions for each in terms of what they should or would access in Jira, the separate project approach can help you to assign devs the appropriate security role given the project, without creating a bevy of security roles in a singular catch-all project. 

[Dana Weinbaum]

Thank you for the thorough answer. It all makes perfect sense.