Should a Product be a Project Level or Category?

[Amy Hogan]

We are a cloud software development company with approximately 15 different products. Each product has regular releases (~quarterly) and their own backlog of enhancement requests/bugs, which we typically roll foward into each new release. Some products are packaged together for a release so a release may include version 2.3 for product A and version 5.1 for product B- becuase they interoperate.

I am piloting Jira and Confluence (and some Agile) and am trying to figure out the best structure for these projects. Shoud each product be its own project and then manage versions within it? Or should a product be a category and the project be the releases? Some of these products have been around a long time- so we may end up with years, potentially decades of releases. Today we use QC and each release become it's own project with all the defects remaining open migrated into it.

Thanks in advance for any advice!

[Evelin]

Sound like separating into projects for me, too. With own versions, components, and so on. To group the projects that are released together you can use project categories. They are helpful to organize the project list, and you can run search queries like category = productgroup1 AND status = resolved. And as Timothy mentioned already, Agile boards can handle more than one project. You could use a board per product group and add pre-defined filters for the projects to switch between them.

[Timothy]

If each product has its own version, it's better to seperate them into different projects. This will allow each "set of version" to live in it's own context and not run into the issue where product A and product B having the same version number.

This concept also works with JIRA Agile as one board can include multiple projects.