We are using Jira heavily in our day to day development. I'd like to see if there are any best practices in creating project components in Jira?
For example, in your opinion, is it better to create a component for each development module in Jira or maybe finer-grained components are preferred by your team?
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.
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):
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.)
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.
As of 4.2.4 it is not possible to version components, only projects. Keep that in mind if you like to use the road map feature.
There's a long-standing (7+ years) request to add versioning for components:
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
I've got another take on components now.
With customers I refer to the Components field as:
A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.
and then I say:
If you don't care about automatic assignment, just treat the components field as a convenient system field.
So to answer the original question again, ask yourself if you assign issues by team or by the fine-level you referred to?
Probably the former.
JIRA designed to have every component of project to have same set of version numbers, so if you want you components to have independent version numbers you either need to set up a different project for each component or use a plugin developed by me that allows component specific version numbers and at the same time allows grouping of components into a bundle. The plugin is "Component/Subcomponents/Bundle Versions for JIRA" and available at Atlassian Marketplace. More information is available at atlassian plugins help page. Another option is to force every component of the team to have the same set of version numbers. Otherwise it is very difficult to select correct version numbers for components.
We use a 2 level component hierarchy (thanks to greenhopper ...) - Themes and Epics. The build in Greenhopper Themes and Epics don't let us aggregate and report the way we want, and this does the trick pretty well.
