How to track products?

Question

Our organization has many teams and even more products.  Teams work on more than one product.  A product may be worked on by more than one team.

After researching for a while, I've seen most people recommend that a separate JIRA Project be created for each team.

I am trying to figure out what the best way to handle the linkage between issues on which a team is working (e.g., epics, stories, tasks) and the particular product(s) to which they relate.  My requirements are:

* It is easy to add new products across all teams
* Ideally no custom field needs to be added

I was thinking that perhaps the Components field could be used for this purpose.  A new component would be created for each product.  As others have noted, the downside is that Components are project-specific.  But, I found the Octo extension which seems to solve that problem.  You can also then create different Fix Versions for each product and associate the components to these versions.

Does it make sense to use the Component field in this way?  Has anyone else needed to solve this type of problem?

Is there a better way to track work on products when different projects are used for teams?

Patrick Wright · Answer

And I'm not entirely sure what our needs are.  Right now, we are tracking products in a very poor way (via a custom field that never gets updated so most people put a default value).

My current idea is as follows.

Use a hierarchy of components for product families, products, etc...  For example, suppose my company works on two product families: Laptops and Cellphones.  Under the Laptops, we make 3 models: LT123, LT456, LT789.  Under the cellphones, we make 2 models: CP14, CP2000.

In JIRA, I would create components named: "Laptop", "Cellphone", "LT123", "CP14",... then use Octo to organize the hierarchy correctly.

I would use Fix Versions to manage the releases of the various products.  For example, Fix Version "LT123-MVO1" would be the release for the first "minimum value offering" of the LT123 laptop.

I believe that, with this structure, it is easy for the developers to assign their work (epics, stories, tasks) to the associate products.  Also, since the Components field allows multiple values, developers can work on a single item that affects multiple products.  For example, if a story affects a common piece of hardware used in both our laptops and cellphones, I could assign the "LT123" and "CP14" component to it.  If the change effects both product families, I would assign the "Laptop" and "Cellphone" components.

Do you think this workflow/architecture will be successful?

Vronik · Answer

Hi

Answering this question is complicated from the perspective that each person uses it according to their needs.
Personally, I have found the component field very useful, also the use of labels, version numbers and of course the Octo extension can be very useful if you have many things to group.
It would be good to think about which of all the options is the most generic to avoid having to have several solutions to the same situation or having to make different customizations.
I would recommend the components and labels as a first option, but before making the decision, make an assessment of the impact, the coverage of the solution and that nothing is left out or is an exception.