JIRA: Epics vs Labels vs Components

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?

64263 次浏览
小开
最佳答案

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.

小开

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.

小开

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.

小开

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


提交答案