Jira Components. How BigPicture handles them?

[#1]

Components are subsections of Jira projects. What makes a great real-life component? A plug-in for a bigger software solution, a bus route, a marketing campaign, or perhaps a country market in a multinational company – are all examples of industry-specific components. How to make the most of Jira components in BigPicture?

First, let’s put components in context. How are they different from Jira’s issues, versions, labels, or projects?

What are Components?

Components are containers for issues. They sit in between projects and issues but are closer to projects in how they behave. For instance, you can set a default assignee for a component. This will override the project’s default assignee when you are setting up a new issue within that component.

One needs to be a Jira project admin to manage components, another reminiscence of Jira projects.

Components have leads (usually the responsible team lead) next to the default assignees. That also indicates that the component is something more profound than a mere issue or task.

Isn’t the following excerpt a great explanation of components: It’s a good idea to give a description to a component. Component descriptions appear as a tooltip when a user hovers their mouse over a component label? Clearly, multiple labels-components per issue are allowed ;)

Figure 1. Components of a Jira project. Get to them from the project’s menu, by clicking the ‘Components’ item.

No surprise, bringing components to a Jira project results in the ‘Component’ field being added to all the issues in that project.

Components vs. versions

Versions, like components, are containers too. But versions get automatically added to the Jira project’s roadmap. Hence, they have to have start and end dates. Later, once “released”, the versions get moved to the changelog. Components neither have start and end dates nor get posted to the Jira roadmap and changelog. They are just containers.

Components vs. labels

Labels could theoretically function like components, but in reality, they rarely do. That’s because anyone can define a new label on the fly, by free typing within the ‘Label’ field of any Jira issue. The ‘Components’ field, on the other hand, has a predefined (by a project admin or Jira admin) list of values. Components are more formal labels, so to speak. But this is for a reason. Jira components originate from software components and were invented to organize computer code. Labels, on the other hand, were intended for just about any industry, not just software development.

***

Jira’s components, versions, and labels all fail at one thing. They are not capable of sub sub sub hierarchical structures. They are flat. Here…

BigPicture kicks in

First, we need to add Jira components to the scope of a BigPicture initiative. Have a look at figure 3, and take note of two things:

1. Not only have we added the ‘Software – LeSS’ Jira project to the scope of BigPicture’s ‘Software Development – LeSS’ initiative.
2. We have also ticked ‘Components’ in the ‘Task types’ combo box.

Figure 2. Adding Jira components to the scope of a BigPicture initiative.

While still in the configuration of the BigPicture initiative, there is another crucial step to take. Remember how we stated that components, labels, and versions of Jira all fail at one thing, namely at being bricks for nestable hierarchies? The following configuration view lets you build 2-, 3-, and whatever-number-of-level hierarchies in BigPicture. In the example below we are designing a simple 2-level hierarchy. Jira components will be the parents of tasks.

Figure 3. We have preset a simple 2-level hierarchy. From now on Jira components will group Jira issues / BigPicture tasks.

The resulting BigPicture view presents itself in figure 4. Note that:

1. Components indeed make the hierarchy.
2. We have added the ‘Components’ column to the view.
3. A task can belong to two or more components, and the first component (alphabetically) is decisive in terms of under which component a task sits in BigPicture. In our example, the ‘As a user I want to be able to have multi-channel communication options’ task sits under the API component, and not under the Plugins component.
4. We have narrowed down the view to just components using the JQL.

Figure 4. Jira components in the BigPicture Enterprise’s Gantt module, here renamed Roadmap.

Other modules of BigPicture take advantage of Jira components too, especially Scope, Board, and Risks. 

1, 2. We have added the components label to the risk card (within the ‘Software Development – LeSS’ initiative configuration).

3. We have added the ‘Components’ column to the risk register. Now, we can sort the risk register by that column.

Figure 5. Jira components seamlessly flow into BigPicture. Risks matrix and register are just an example. There is room for Jira components is in the Scope and Board modules, too.

Conclusion

Jira components resemble Windows or macOS folders. Rather than files, they store Jira issues. Components are derived from the software industry, especially when parts of the product or solution have dedicated teams, or when a collection of issues make a deliverable. Unlike computer folders, a Jira issue can belong to many components. BigPicture portfolio management app recognizes Jira components, with the tree-like hierarchies based on components being the foremost gain.