When to create multiple projects on JIRA

[alokraop]

Hey i'm trying to understand what would be a basis for splitting JIRA work for a team across multiple projects.

Our team works on a set of utility web services, which builds capabilities for each new client we on-board to consume out API. Each of these clients tend to use our service for their own "projects" which span across multiple services and workflow systems. Currently we make a new JIRA project per "client project" that we get work for, but it all involves work on the same set of web services. 

The rational that we have for splitting them is that each of these projects need separate reporting and putting them all together would remove the separation that we get from putting them in different projects. Some of these projects consist of work that might span multiple epics, so we can't even create one epic per such project. Plus even semantically all this inflow of work IS a "project".

On the flipside, it becomes cumbersome for the developers to add tasks and mark them as done across projects. Each developer does have a dashboard configured to show all the tasks that he/she has been assigned though, so that's not much of a problem.

The crux of the dilemma though is that i want to know if one JIRA "project" should be synonymous with one "product" under development, or one "project" that requires the development on the product.

I'm totally new to JIRA so i don't know if there's already an implicit convention that is applied for this sort of a situation. Thanks in advance for the answer.

[Tarun Sapra]

Hello Alok,

If it's a single product that you are developing then my suggestion to you is to stick to a single project until you have a very strong reason not to do so.

Here's what I would do to address all the concerns which you have raised.

1) Have a single Project for my product.

2) When a new client comes in and my team needs to create API for this client then I will add a new component in the project. This new component represents the client.

3) Now, while creating stories or epics I can choose the components i.e. choose the client for which the work is being done.

4)In JIRA all the reporting and boards are builtin on JQLs (JIRA query language), now you can create boards based on the project =myProduct and component = client, thus you can have client specific boards.

5) In JIRA , reporting and scrum sprints are specific to the boards thus you now have separate boards based on different client and your team can focus only on the board which is being worked upon. Once the sprint is over the board can be no longer in use as there are no more issues to be done for that specific client and the team can move onto next client with a new board.

6) Best thing about this approach is that you as an Product Owner can get an overall idea and reporting across all the clients easily as all the issues are created in the single project thus reporting and writing JQL for creating reporting becomes much easier as there is now only 1 board to handle.

7) Only drawback of this approach is that in JIRA releases are per project instead of per component , thus you would need to name your releases like "release-Client A" , "release-Client B" etc

Now, instead of components you can also use a custom field with a drop down of client names if you wish and everything else remains the same only in the JQL eury you replace custom field name with the component.

[Thomas Schlegel]

Hi Alok,

there is no universal answer to your question. It depends...  

You said, development is working on the same services for different customers. Do you already use the components field? If not, you could add your customers as "component" to one project and add these components to the issues you work for a specific customer. You can also add more than one component (e.g. customer) to an issue.

You can have different agile boards in one Jira-Projekt, so you can create a board for every component-customer.

Reporting must then be based on project and component. 

Maybe this might be a possible solution for you.

[Karalee Kikiros]

What Tarun and Thomas have mentioned is great. I thought I'd just mention that a couple of addons may help you with a couple of the problems that you mentioned. One is JIRA Portfolio - this can help you track work across multiple projects to one release and/or one theme (or category in layman's terms). The other is Tempo Teams - if you find that you are struggling to accurately predict user capacity, this can be a godsend.