Projects vs components

[Test user]

I know there are already a few questions on this topic, however I've read a few and wanted to confirm my approach makes sense.

We need to manage a group of products, all of them are applying some predictive models to improve manufacturing processes throughout its different phases. So, overall:

-All products using similar technologies, also using similar User interfaces from a standard template etc.

-The development teams are the same for all of these (there are a few teams that work together on different parts (i.e. Frontend, backend, MLOps)

-No issues with everyone having visibility over everything 

-Some developers might even be working on more than one product at a time

-Each of these products is quite lightweight and can be developed in a couple of months

I think using just one project with multiple components is the way to go (one component for each product). This way:

-Prioritization is easier when involving tasks from different products  

-Just overall easier for developers

-Easier to follow by managers whose teams work on different products

-De facto standard way to work (easier to manage way of working having to control just one Project vs say, 10 or 15 smaller ones.

The only "con" I can think of is releases, but I think using naming conventions for the releases con be enough to manage them, not a big issue.

If needed we can then create boards to get the details of a project or team if needed,  to reduce complexity of looking at all the information. Maybe even create tags to see boards per team (for example creating a tag for team "Frontend" and a board for frontend developers to see all the work they need to do across products, although I guess this you could do with multiple projects too)

I would really appreciate feedback on the approach, and see if anybody sees a better way to do things here, I am open to other ways of working, but main focus is reducing administrative work and making it easy for developers to track and log progress, we really want to keep things lean and simple.

Thank you!

[Walter Buggenhout · Accepted solution]

Hi @charlymune and welcome to the Community!

The difficult thing about this discussion is that there is no right or wrong. But it seems you have put some real thought into this and what you are saying absolutely makes sense.

If it was me, I'd probably set up different projects: one project for each product, as it would make it easy to track the history of each product separately. To make sure your team has a single place to work, I'd make sure there is 1 scrum (or kanban) board that groups all the issues across all projects for your team.

But I don't know anything about your products and how important it is to potentially manage product backlogs and history separately. So I'd say: give it a try and see if it works for you.

If you come to the conclusion that it would be better to reorganise, you can move issues across to a different project later on as well.

Hope this helps!

[Test user]

Hi Walter,

Thank you for the welcome and your input!

Yeah, the more I look into it, the more ways I can see to organize it. Quite honestly, the separation in Projects/Components might not end up being so important, but rather the "single place to work" for each team/developer.

I started thinking in my way to simplify, but really, for the end user, it doesn't matter that much as long as they have that unified board to see all their issues across projects.

Thank you for your reply, it gives me confidence to just try the best we can come up with, as long as we take into account the needs of the devs so they find it easy to structure their work.