What is the difference between Component and Epic?

[darshan lakkur]

What is the difference between Component and Epic?

[Katy Šrámková]

Best answer is here: https://www.linkedin.com/pulse/stories-vs-epics-components-modelling-product-jira-piotr/

Main takeaway: Epics are groupings for stories, can go cross projects and should have an end in time. Components more "product categories" that are related only to one project, timeless and kind of endless in scope and can be divided in "sub-products".

[Calogero Bonasia]

start reading this page: https://confluence.atlassian.com/display/AGILE/Configuring+Versions+and+Components

[Nic Brough -Adaptavist-]

I'd also look at https://confluence.atlassian.com/display/AGILE/Working+with+Epics for a description of Epics - they are VERY different from components.

[manjunatha k r]

Planning to use both JIRA components (i,e for grouping issues under a project into needed logical components) and EPICs (i,e used as features to group the related issues) in my project.

JIRA Issues/development stories will be linked to both components and EPICs in my project for a specific release/version to be released.

With the above project configuration/structure in Jira, I would need to track the followings:

1) In a specific release/version, how many features are assigned and it’s impacted Components details.

2) The progress status of each Component for a specific feature.

Here mainly a Feature will be impacted on multiple components to develop and deliver stories linked into it. 

Please suggest, whether it's a best practive in Agile do this or any other suggestion???  

[Nic Brough -Adaptavist-]

Ok, that's the right way to use them.

Both of your reports can be done by creating and saving a filter for the issues you want to track and use it in some dashboard gadgets - they can slice up your data by component, epic or whatever.

Agile doesn't have a lot to say about this, it's more about the planning and visualisation of "now" that it does.  You can carry on doing things in an Agile way, and group your issues up with Epics and Components fine.

[manjunatha k r]

Thanks Nic Brough for your prompt confirmation.

[Sabrina Gelbart]

Can you provide concrete examples of what you mean? E.g., what would be an example of a component vs an epic?

[Nic Brough -Adaptavist-]

An epic is a big chunk of work made up of many parts (stories), a component is something you put on a story or sub-task to show that it relates to a part of your project.

[Sabrina Gelbart]

ok, so an epic would be like "user accounts" and a component would be like "db", "backend", "frontend"?

[Nic Brough -Adaptavist-]

Assuming the "user accounts" is a far-reaching job like "merge two companies accounts together" or "implement user accounts across all our applications"

[Juan Francisco Lablanca]

Hey there,

would it be correct to say, that: 

- Epics are to be used to slide your product into smaller features or group of features, and therefore to be used by product/business folks

- Components are rather the parts of the software or system your product is made of, and therefore to be used by architect or developers?

cheers!

[Nic Brough -Adaptavist-]

Not really.

- Epics are used to gather stories into highly related groups of larger features or groups of features, and are there to be used by anyone, although generally, product owners should be in charge of them

- Components are pieces of the *project* you are working in at a low level.  Also to be used by anyone, but the main users are likely to be developers, project leads and the people in the project who understand how to break down what the project is for.

[NoreenC]

This was the most easy to understand answer for difference between Epic and Component.

[Paul Lacey]

Our system is comprised of 89 major features. We use component to identify these 89 major features. When we release a new version of the product (system) we introduce new versions of the major feature(s) that been improved.

Using component lets us track across epics/stories/defects per major feature. 

System documentation in Confluence and other repositories is also organized by these 89 features. Components allow us to track costs & quality per major feature.

[Mark Risman]

One other difference to point out is that Epics are themselves issues, while components are not. That's why Epics have an issue key, which contains a number. This tells us that today we have this particular epic we are focused on, while tomorrow we'll be creating a new epic or story, and so on. This is also why an epic, like other kinds of issues, has a Status. So, at some point, an Epic can be considered Done. Epics are designed to be particular initiatives or projects that come up from time to time. Unlike other issues (such as stories, tasks, or defects, for example) though, epics are meant to be bigger. That's why they can have stories or other kinds of issues inside them.

Components, on the other hand, are meant for things that are persistent parts or aspects of your system or team. A Feature is a good example of something that could be considered a Component, as others have mentioned. A Component could also be a sub-feature, or aspect (like something non-functional like security, accessibility, or documentation), or even a theme (like usability).

Also, if you're familiar with the Agile paradigm called FEST (Feature, Epic, Story, Task), these JIRA features fit in nicely with that hierarchy. A feature could very well be represented by a Component in JIRA, an epic would be, well, an Epic, and so on

[Lavanya Tamarapalli]

Currently,  we are using components to manage sub projects/modules of a project. A sub project can have multiple epics, and each epic can have multiple stories

[romelperez]

I found out that they are just a different way to tagging issues in this video: https://www.youtube.com/watch?v=NrHpXvDXVrw. Don't remember when he said it.

In my opinion, I would rather use Epic links instead of components because you can filter it better in Agile Boards. But just an opinion.

[Nic Brough -Adaptavist-]

No, they are absolutely NOT "different ways to tag an issue". You've misunderstood what he's saying. For example:

• A component belongs to a project. An Epic can be linked across many projects.
  ...
• Component is stored as a field on an issue. An Epic is an issue in its own right and has to have issues linked to it.
  ...
• A component can have a user associated with it. An Epic can have one or many users, dates, text, numbers and any other fields you want added to it
  ...
• Components allow you to group, find and do simple reports on issues. Epics are there to group issues, break down the overall piece of work into many pieces, reporting on progress, effort etc etc etc
  ...

The list of differences goes on. They are not just simple tagging items (in fact, if you want to claim something is for simple tagging, use the "labels" field, which is different again)

[romelperez]

Yes, I misunderstood that. Thanks to clearing it.

[menno]

Calogero, your link returns some 'Page level restriction' error.