Effective management hinges on the ability to categorize and report on tasks with precision. For project admins using Jira, components and subcomponents offer a powerful way to streamline workflows by grouping related issues, facilitating better reporting, navigating issues faster, and enhancing team efficiency.
As Jira Software has various type of native field, project administrators can discover that they want more fields for classification, which they can subsequently utilize in dashboard widgets and filters. They can use components, labels or custom fields to group tasks. All three features can be a good way to sub-group issues around the project. Each of them has different use case and potential. Now, we’re going to take a closer look at the components.
Components facilitate issue grouping in your project according to departments, workstreams, or product aspects. Admins can assign component owners to automatically assign to them issues with those components.
In a nutshell, components can help you group or sub-categorize issues into smaller pieces of work. Components also help with filtering and reporting - dashboard gadgets can use the component field.
Example: You can add a graphic component to all issues that require graphic work. Celine is the component lead and its configuration is set as default, so all issues are automatically assigned to her.
❗️ Components are available only for company-managed projects. It’s still an Under consideration ticket.
❗️ Project admins can configure Jira components. Other project participants can view, search, and add components to Jira issues.
Now, Atlassian allows you to switch between Jira and Compass components. Which one should you choose for specific situations?
Use Jira components to group issues within your project around features or teams. Designating features is helpful there. Name component owners and auto-assign matters to them.
Use Compass components to organize issues around software and more extensive architecture. As Compass is designated for tech projects, components are perfect for developers teams.
Components are a useful tool for project admins to sub-group issues. However, there is a limitation that requires additional development and workarounds. While you can assign multiple components to an issue, you cannot categorize them hierarchically. Achieving this requires extra custom fields and configuration.
Project admins need the ability to subcategorize and create hierarchical subgroupings within components when managing large-scale projects. They could benefit from hierarchical subgroupings within components to better track related tasks across different teams or modules.
All components are on one level. If we assign to Celine also environment design, this component won’t be a part of the graphics - it will be a different component with the same scale, and that’s not our intention.
In native Jira configuration, you must create many other custom fields or use labels. This method is not perfect in the project management spirit and generates chaos. Also it won’t be effective in reporting section.
This scenario corresponds to this support ticket for Atlassian since 2002. It’s a little bit longer than 11 years that Harry waited for the Hogwarts letter.
Atlassian Community Use case:
The user wants to create a hierarchical business capability model to represent their product/platform. They envision a structure like:
They intend to link various components (e.g., test cases, bugs, stories) to these capabilities to gain insights into the health and performance of each capability.
However, the user finds that Jira offers a flat list of capabilities, lacking the hierarchical structure needed for effective modeling. They attempted to use labels and dependencies to mimic this setup, but this workaround feels inadequate, as the default views do not support the desired hierarchical representation.
We need one field, with many levels, easy to configure and useful in filtering and reporting. So what’s solution can we suggest?
You need a subcomponent workaround if you want to create components in a many-level hierarchy and still be able to use them in reporting and filtering. Native Select List (cascading) custom field allows for creating only 2 levels of hierarchy, which usually is not enough for project admins.
We’re project admins for a Harry Potter Game for PlayStation development project. Crafting a game of this magnitude is no small feat - it’s a multilayered endeavor that demands meticulous project management and coordination.
This involves breaking down the game into subcomponents, allowing us to focus on each element with precision. For example, the main category of Graphics and Animation should look like this:
Graphics and Animation
We need a three-level cascade to create subcomponents. By organizing our project in this way, we can better manage resources, track progress, and maintain the high standards expected of a game set.
Our recommendation is to utilize the Custom Fields Suite app. Using Multilevel Select, the custom field has it all. As you can see, we were able to define subcomponents with a multilevel cascade field right on the create issue view.
After creating the issue, subcomponents are saved and immediately visible in the issue view, clearly displaying the structure. Users don’t have to search for this information or learn new interfaces, as everything works smoothly, just like the familiar native Jira Component field.
❗️ This solution can be used in both: team- and company-managed project and for every project kind: business, software and service.
The structure of subcomponents for such a comprehensive project is long and complicated. Admins could spend hours creating many custom fields for it, but in Multilevel Select, custom fields are bulk options and import/export from CSV or JSON. So, creating a list with 8 main categories with 3 levels, all of which have more than 3 levels, took us about 10 minutes. Detailed configuration is available in the documentation.
Our Harry Potter game is definitely a multi-project task. The multilevel select field can be assigned for many screens and projects, so it’s easy to reuse, and admins don’t have to configure it multiple times. You can translate the options in the field into different languages—something impossible with native Jira Components. For multilingual teams, this feature can be a valuable addition.
If we were using components, we would assign tasks automatically with the component lead. The Diagon Alley issue would go to the graphic lead without manually clicking, but also other graphics issues, without chances to assign them to other graphics. If the Diagonal Alley should be created by Kate and the Forbidden Forest by Paul, these tasks will first go to Celine as a component lead. But not when using the Multilevel Select custom field.
With automation, you can configure auto-assigning and also assign each subcomponent to another Assignee. So, there is no need to resign from native component features, and what’s more, you can expand them.
A project admin who needs to assess the progress of the "Environment Design" in the Harry Potter game for the PlayStation can utilize the multi-level select custom field along with JQL to streamline this process.
By filtering issues with the specific component "Environment Design" using JQL in the multi-level select field, the admin can quickly isolate and review all relevant issues tied to this aspect of the project. This enables a focused analysis of how the "Environment Design" tasks are progressing, helping the admin to make informed decisions and address any potential bottlenecks in this area.
The formula would look like this: "Harry Potter Game for PlayStation.level2" = "Environment Design"
A project admin also needs to monitor the progress of tasks for the Harry Potter PlayStation project. There is a possibility to utilize the native dashboard to get a clear overview. By configuring the special Multilevel Select gadget - just like any other in Jira - the admin can easily view the status distribution of all tasks related to Harry Potter for the Playstation custom field.
This gadget allows the admin to see at a glance how many tasks are In Progress, Done, or not started yet, helping to track the team's progress and identify any areas that may need attention.
❗️ The Custom Field Suite app can also be used in EazyBI reports where you can display the whole cascades without boundaries.
Effective project management requires tools that can adapt to the complex needs of large-scale projects. Components in Jira provide a solid foundation for categorizing and managing tasks, but when creating hierarchical structures, project admins often find themselves limited by the native functionality. As components are a flat structure, subcomponents can’t be effectively used here without a plugin.
By leveraging the Multilevel Select custom field and integrating it into your Jira workflow, you can unlock new levels of efficiency and precision in managing and navigating complex projects. Whether you're developing a game or managing a tech platform, this tool will help you stay organized, informed, and on track to deliver high-quality results.
If you read it to the end, Custom Field Suite Product Owner Kate sends greetings from Herbology straight from Hogwarts!
This article was originally published on the Appsvio blog.
#AtlassianCreator
Celina Kuziemko - Appsvio
0 comments