Components v Themes in JIRA/Portfolio

[Jay Altschuler]

The intended functionality of how to use story functionality is straightforward. It is as follows:

Initiative>Epic>Standard Issue>Sub Issue

And then, as you desire, you can package issues and epics into versions and ship and use Initiatives to group epics together. Cool. But if you're using Epics as intended, as large user stories that are completed after 1+ sprints and initiatives as containers for features that might contain multiple epics, we're still missing a way of categorizing issues into semi-permanent elements/categories within the application. There seems to be two ways JIRA+Portfolio allows for this to happen: themes and components. Both of these fields could do the job, but they also both feel like after thought, not a prominent way of organizing our work.

Unlike epics and versions, which are clearly the way JIRA wants you to categorize issues, components and themes are not available in the 'planning' side bar, they do not appear on issues as a 'tag', they are really just glorified custom fields.

I'm curious, this is a very obvious need, the features are there but not developed fully. How should we expect JIRA to further develop these features, and in the meantime what would people reccomend?

[Dave Theodore [Coyote Creek Consulting]]

Component/s have a very specific function in JIRA and it's not intended to be used for what you're after.  It's a multi-select field that a JIRA admin can delegate the management of the values to a Project Admin.  It also has the ability to denote a "Component Lead" to each value.  Automation in JIRA can assign the issue to the Component Lead in desired situations.  The use case for something like this is where QA opens a bug against "Database" component.  The QA engineer doesn't need to know which person should be assigned the issue, since JIRA can automatically assign the issue to the component lead.  Generally, a component will be represent a subset of the issue type or a finite category of issue.  

Themes are intended to be an overarching action that you are taking that are not directly tied to a release, or a single piece of work.  Say you're rewriting your app from using php to using Java.  You may want a way to track the progress of that concept, but it isn't something that will necessarily be tied directly to a single release.