Best practice of using components in jira projects

Question

Hi, we are using jira heavily in our day to day development. Wanna to see if there is any best practices in creating project components in jira?

For example, in your opinion, is it better to create component for each development module in jira or maybe finer grained components are preferred by your team?

Cheers,

Answer 1

I would match up the components with your modules/artifacts/jars, so each issue can be owned by a particular module (though it might have dependencies/relationships with others as well).

If you can make a strong case to have finer grained issue management than the module level, consider why you wouldn't also separate the associated module.

Having this 1-1 mapping helps clarify your release schedule, you can easily what issues version X of your project has, and which modules to focus the effort upon. It also helps simplify associations between Jira, the build system, and the SCM, e.g. if you're using Bamboo you'll likely have a build project per module, so you can simply add the association.

Answer 2

Components are like little sub-projects. Projects seem to be most useful when they group people together. I recommend to my clients that JIRA projects reflect the social organization to some degree, at least until the number of projects becomes very large.

Also, avoid the use of a component named "Misc" or "Other". They tend to become waste dumps of issues that no-one cares about.

~Matt

Answer 3

Create a component for each major module, or maybe even system tier (eg Backend, Frontend). I wouldn't go below-module-level granularity. You may add components for supporting activities, such as BA, Testing (agreeing with mdoar)... Components are orthogonal to versions/releases

Answer 4

Most important about components is to be unambiguous and not too many. In our team now, we are migrating to 3 level hierarchy (in GreenHopper sense):

• on the top level you have the BA components which are few and delineated by team (infra, backend, GUI) - this helps BA guys route the request to the correct DEV-team manager assigned as component lead.
• the second level is actual process (in the Unix sense). This is very clear definition. In case an issue maps to multiple processes, we assign it to one of them (BTW, GreenHopper does not allow multiple leaf components, but plain JIRA does). This is done by DEV manager.
• the third level is optional and rarely used, denoting subsystem within the process. We use it when a considerable part of the of the issues are related to a well defined part of the code and we want to track them separately. This is usually done by the developer working on the issue.

In order for such progressive refinement to work, you need to have idea of who is assigning to which component and who is processing the issues assigned to it. The latter is denoted by Component Lead, the former is not explicitly supported by JIRA (or we would be able to say that BA's see only their components, DEV managers, only their subcomponents + all BA, etc.)