Should our team use one project or multiple projects for multiple applications

Question

There’s already a lot written about this, but I can’t figure it out. I’m looking for an answer to the question whether, with our team (one team) that works on multiple IT applications, we should use one project or rather a project per application.

I read that the principle is to use one project per team. However, in our case, we come from multiple teams that each worked on their own IT application (and therefore on separate projects), but this has now been merged into one team that works on multiple applications. Both options have pros and cons.

For me, the biggest disadvantage of working in different projects per application is that with our current license, we can’t use the timeline (we bundle the projects in 1 central project to use the active sprint board). We work in Scrum, and the sprints are created in the central project, which means the sprints are not shown on the individual projects, making the timeline hardly useful (we don’t work with start and end dates on tickets). On the other hand, it should also be immediately visible which application a ticket belongs to, and that seems harder to visualize with one project (possibly by using components, but I find that not very clear).

What would you advise?

Alan Tragarz_kwbge6 · Answer

Also think about the Fix Versions or Releases. I have several teams that work on different products but all releases occur post sprint via a single fix version, for release manager to coordinate. Having multiple projects means that each has its own fix version and even if you use cross project release its a pain for our release manager.

Rudy Holtkamp · Answer

Hi @Lieselotte Swinnen ,

What I would recommend is to use one project and make for each team a separate board in the project. Also make the team field required. 
The board filters should be something like, for two different teams:

project= "IT applications" and ("Team[Team]" = "Blue team" or "Team[Team]" is empty)

project= "IT applications" and ("Team[Team]" = "Red team" or "Team[Team]" is empty)

Then you can use the the timeline, each team can use it's own board and sprint. And when an item has been created it will automatically show up in the board of the selected team.

It is even simple to move an item from one team board to another, just by changing the team field.

Thorsten Letschert _Decadis AG_ · Answer

Hey @Lieselotte Swinnen

Great question. To confirm, I understand your use case: you're not planning to run sprints per application, correct? If so, I'd go for the "one project" approach, due to several advantages:

Single backlog, single sprint, single source of truth

Timeline, sprint planning, reports → work out of the box

Matches Scrum reality: the team commits as one unit

Easier prioritization across applications (“what’s most valuable now?”)

About your visibility problem:

Having a dedicated (single select) custom field or using components should both do the trick - components would include some advanced features like component (or here "application") leads that can be used for assignments, etc.

Either way,

* Adding the field being used for application assignment to your card layout via board settings > layout > card layout
* Using distinct colors per application assignment via board settings > layout > card colors
* Adding quick filters per application via board settings > layout > quick filters

should all help you overcome the visibility constraints.

Regards from Germany,
Thorsten