products vs team

[Nicolas Gonthier]

Ok I can't put my head around this.

We have : 50 products, 4 teams and each product is maintained by 1 or 2 person (sometimes depending on priority, it will be 4-5 person for one product)

Sometimes it's a project and sometimes it's a small change/fix.

Generally speaking, we don't want to follow release per product, we want to follow the teams.

Each team will have a board to execute task from the different product (SCRUM or KANBAN)

We don't know which road to take between :

One project, with one board per teams filtered on component(product)

vs

One project per product with one board per teams filtered on project

It could work both ways, one project with component as product is simpler put we are afraid to be missing on something (plug in, version, granularity of component), and for one project per product, we are afraid that it is going to much of trouble for what it is going to give us.

Any Ideas?

[JimmyVanAU · Accepted solution]

Hi Nicholas,

There's no right or wrong answer, but my suggestion would be to use one project to start off with, with multiple boards.

If you decide this is too complex, you can then make multiple projects and move issues from one project to another. Creating new projects based off your initial project is easier than consolidating projects.

[LarryBrock]

I agree with @JimmyVanAU - keep it simple until more complexity is needed.

[Ashkan Malekly · Accepted solution]

Hiii @Nicolas Gonthier 

As we have some products in our company, we define a project per product but the version and component are different. If you want to have the same version and component you can define one project and each widget also defined as initiative or epic (if you have portfolio add-on I suggest you define initiative to have the hierarchy). In our company we use the component as teams job (for example front end, back end)