JIRA: Epics vs Labels vs Components

Question

This blog has a definition of epics in JIRA:

Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.

So if (as a product owner) I have a large feature I want delivered that will comprise many smaller tasks and likely span sprints, then an epic is a good choice.

However, I could just as easily create a (using the example from the blog) "Account Management" component, and any task related to that feature have that component assigned.

Similarly I could also just as easily use a label of "Account_Management", and any stories/tickets that are a part of the Account Management feature simply get tagged with that label.

So my question: why/what circumstances would you use an epic? why/what circumstances would you use a component? Why/what circumstances would you use a label? Ie - all three (epics, labels, components) seem to serve very similar purposes (grouping a collection of issues), what's the difference?

Speciosity

Answer 1

With labels and components if you want to select a group of them you need to use issue search. If you are using epics you can use issue search as well, but you also get built-in functionality in JIRA Agile.

In the backlog view of a JIRA Agile board you have an Epic tab. This tab allows you to select the issues associated with individual epics. Plus it has functionality that makes it simple to add new issues to an epic. The final advantage is that the epic name is displayed brightly coloured alongside the issues in the list. This can be very useful when viewing the backlog and getting a feel for what work is coming up next.

You can see more about epics on the Atlassian Working with Epics page.

Components are useful for the technical team as they can span across many epics. A typical component might be 'database' or 'UI'. JIRA offers the option to assign work for a particular component to a particular JIRA user. For example, all issues created with a component of 'database' could be assigned to Jill Smith.

Labels are much more adaptable and they have the advantage of allowing multiple assignments (so more than one label can be associated with an issue). With labels it is very much up to you how you use them.

Marasco

I would add that labels are cross cutting. You can label various types of issues in Jira with the same label. This way you can create a custom flag such as TODO, NEEDS ATTENTION, REQUIRES DOCUMENTATION etc. You wouldn't create epics or components for that. – Overhaul

Answer 2

Epics by definition are short-lived issues when compared to the project as a whole. Components and Labels on the other hand are forever. And, you should stick to use them by their true meanings however tempting it may be otherwise.

Create Epics for features, or as mentioned by @Sateesh, for bigger stories. They should solve their purpose, and once the business need is done for, they should then be closed/done.

Components are not features. They are the technical parts of the system. They can also be used for categorizing your parts or... well, components :P... of your product.

Labels can be anything, as mentioned by @barnaby. Typically, they are keywords, catch-phrases, words people may want a task to relate to, etc. I use it mainly to make issues better searchable from a long-term perspective. There is a JIRA plugin which gives you a JIRA label cloud (for purely fancy purposes, I feel :D) that might interest you, too.

Dilworth

"Components are not features." -- that's an interesting distinction, what's the difference? Is there a danger in having a roughly 1:1 mapping of component to feature? – Speciosity

There are no dangers as such. Just inefficient, that you will end up either using them only one way (as a component or a feature) or mixing them, that's all. I thought a lot about how to explain the difference exactly, and I hope the following will make a good example. – Dilworth

I'll take a technical debt (big) task as an example, because it in itself is a very technical issue, but helps see the gap better. Say "Refactor Payment Module" is (assumed to be) a mammoth task spanning over multiple sprints. Hence, you will want to create this as an Epic. And, the components for this issue would be Payment Module. Hmmm... just thought of this: In other words, Epics describe the broader goals to achieve, and once achieved, they should die, whereas Components simply denote parts or areas of application, which will have meaning forever. – Dilworth

I'm not sure these delineations really resolve the question at hand. Components and labels are not forever - a system design may change such that a given component no longer exists. A label may become irrelevant for a variety of reasons. When you break it all down, an epic, label, and component are all simply categorizations with varied restrictions on what you can do with them (albeit odd restrictions - a story can't be required by two epics? A story can't involve two components?). I don't find Atlassian's design very prescient. – Adelleadelpho

It appears components actually do allow multiple assignments, which is good, so the delineation between components and labels becomes more useful as components are centrally controlled whilst labels are free-form. – Adelleadelpho

To add to this, components can also be assigned a 'lead', which is useful in a variety of scenarios. – Emotive

Answer 3

Addition: Atlasian now have created a new article explaining this from their perspective.

https://www.atlassian.com/agile/delivery-vehicles

My opinion / usage.

Labels and Components are almost straightforward and well answered already.

Components examples

• Android client app
• Server API
• Database etc.....

Labels examples.

• Business logic sectors (ex Orders,Invoices,Users, Products)
• Code Quality Improvement
• Refactor
• Usability
• User request/complain Generally whatever helps categorize things.

But let me give my two cents about Epics because i find this phrase way too generic.

Epics are significantly larger bodies of work

Larger? 10 Sprints? 10 Stories? 20 Stories? or what?

Personally i would classify Epics as Goals or Major Releases.

At a Yearly / Quarter Retrospective your company holds a meeting with all members and stakeholders , and concludes to the following

1. We need to target more platforms (epic = Platform Expanding)
2. Our support personnel needs more tools to handle issues. (Enrich Support tools)
3. The software is too hard to use! ( Redesign UI UX)

This would mean 3 epics with set of stories to cover each of those generic requirements

Dimorphous

In the context of the conversation here, there's another term Initiatives that might be synonymous with Epics. IMO Initiatives is more understandable, while Epic, as we can see, is fuzzy. As long as your team(s) are on the same page as the definition, though, you can do what you want, generally. – Dilks

This should be the answer. So many answers I see here and the internet with no examples. This is the only one with the example - the original answer is pathetic @BarnabyGolden – Saleswoman

Answer 4

Epics are bigger stories which require more than one sprint to complete. One Epic may involve several user stories. Each user story may belong to one or more Component. Say, you have an epic airline availability search. This may have multiple User stories like OW search, RT search etc., Some or all of them may involve components like cache, travel policy & booking engine.

Labels are just for convenience. It may not have physical significance.

Negotiable