How are your Jira issues organized? Chances are, the answer is “poorly.” The core of issue organization in Jira is the project. Projects are the highest level containers for issues in Jira. Your Jira projects should reflect real projects or teams at your company. Projects can be small, but commonly they are huge, with hundreds or thousands of issues. That’s why it’s necessary to get into more fine-grained grouping data.
Components
Jira project components are generic containers for issues. Components can have component Leads: people who are automatically assigned issues with that component. Components add some structure to projects, breaking them up into features, teams, modules, subprojects, and more. Using components, you can generate reports, collect statistics, display them on dashboards, etc.
Project components can be managed only by users who have project administrator permissions. They should have unique names across one project. Nothing prevents users from adding issue to more than one component.
Versions
Versions are another type of container that reflect product or project versions which are particularly useful in software development. There are two types: Fix Versions and Affects Versions (the difference is explained here). When a version is created it has the status “Open” and is automatically added to the project roadmap. When a version is marked as Released it is moved from the project roadmap to the changelog. These versions then fill out both the roadmap and changelog that you see in the project view tabs. Like components, only project administrators can create new versions. Thus, both components and versions have a predefined list of values. Learn more about versions in Jira.
Labels
Labels are the simplest way to categorize issues. Anyone can create new labels on the fly while editing an issue. All project labels are displayed in the Labels tab of the project as a tag cloud.
Users want more
Projects, components, versions, labels… looks like enough ways to organize and search issues? Yes… almost. The main problem is that none of these models support hierarchical structures. They are flat. What users often want to build is subcomponents, subsubcomponents, subsubsub… The same is true of versions and tasks.
Jira projects should reflect real-life projects, where everything is part of something bigger and everything has some smaller parts. That’s why the lack of hierarchy creates a large area for improvements and extensions, including Subcomponents for Jira.
The main purpose of Subcomponents for Jira is so that users can convert their existing flat list of components into a subcomponents hierarchy.
Within the hierarchy, Jira users can easily find issues at any level or depth. It makes it easy to find all the issues that makeup one aspect of a component of a product, but with the structure of components. It’s just one small JQL query “component in subcomponents(projectKey, component)”.
Subcomponents is a quick way to start getting more out of Jira components. Check it out on the Atlassian Marketplace.
