Single Jira project for multiple Scrum teams

Question

We're going to develop a Java web application (frontend + backend's microservices) using several Scrum development teams. One team is resposible for the core product modules (microservices). Some other teams are responsible for some other modules (microservices). And yet another team is responsible for development of the frontend.

All the design and the specifications are kept in Confluence.

Is it a good idea to create a single project in Jira and configure it so that each team sees only its tasks? Or is it more convenient to create different projects in Jira for each team?

What are pros and cons of each approach?

Answer 1

I've found that Jira projects best equate to products. This enables better use of the functionality around Releases, Components, and test case management (if you integrate that with your Jira instance through a plugin).

In your case, you need to decide if your web application is a product or if the different microservices are each a product. I prefer to have the customer-facing entity be the product, regardless of its architecture, but I can see advantages to both. This depends more on how you want to track and control revisions to the system - I personally favor versioning the system as a whole, so I would want to uprev the system every time any microservice changed and would want to use Jira to track those system level versions.

With the one-project approach, you can create separate boards for each team yet leverage the overall Product Backlog in a way that would support scaled frameworks such as LeSS and Nexus and take advantage of some of the built-in Jira functionality.

Answer 2

I would keep everything in the same project since you are working on a single web app. You can create multiple boards in Jira (one for reach team) and manage each teams workload through these boards. Speak to your Jira Administrator to design the project.

The product architecture sounds like it is layered (front-end, product micro-services, etc). Sounds like there are multiple dependencies between the teams. Apart from the Front-end (for which I assume you are using user stories with acceptance criteria) how are the requirements handled for the product micro-services?

Maybe you could think about rearranging the teams so they have input/skills/expertise from all the product layers. Using the layered cake analogy, rather than having separate teams deal with each layer of the cake, each team deals with a slice of the cake. That reduces inter-team dependencies. Just make sure there is some kind of architectural guidance so each team handles the layers in the same way. Any divergence between the teams in the way they approach the layers can be defined as technical debt and dealt with through refactoring in a series of hardening sprints.

Answer 3

Create different projects

Advantages:

• No need to differentiate issues assigned to different teams. Just the fact they are in a given project tells you which team is dealing with them
• No issues with the JIRA inbuilt Scrum functionality although you may see some problems with epics (if stories from an epic need to be worked on by more than one team).

Disadvantages:

• There may need to be a 'feeder' project that contains the backlog before it is allocated to the teams
• You may need to move backlog items between projects
• There is no single, consolidated and prioritised view of the backlog

One project

Advantages:

• One backlog view (and you can use filters to narrow it down to individual team's backlogs).
• One prioritisation.
• Cross-team epics will be easier to manage.

Disadvantages:

• You will need some way of differentiating between teams on issues. For example you could use a custom field or a label.
• You will need to create several boards, one for each team and differentiate them using JQL filters.
• Whenever you add a new issue you will need to indicate which team it is associated with (by setting the custom field or adding an appropriate label).