Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Components v Themes in JIRA/Portfolio

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?

1 answer

1 vote
Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 11, 2017

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.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events