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".
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???
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.
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?
- 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.
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.
No, they are absolutely NOT "different ways to tag an issue". You've misunderstood what he's saying. For example:
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)
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.
Hi everyone! My name is Jenny, a Product Manager at Atlassian. After launching Team @mentions in Confluence, we heard a lot of positive feedback from customers that they love how easy it is to @men...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events