Jira: Using Epics vs Components vs Labels

We’re going to compare Epics, Components, and Labels as they are used in Atlassian’s tool, Jira. To properly use these features in Jira, you must first establish their definition of use and share these with your entire team and/or company. So let’s jump right in. What are these things?

NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.

Epics are simply containers that are filled with user stories and track details for a particular body of work. Use them to capture large pieces of work, provide a high-level description of the work that will be done, and share with the team and stakeholders. Epics often take the shape of specific features, such as login. Unlike Components and Labels, Epics are Issue Types. Setting up an Agile board for Epics allows stakeholders to track stories at a high level and observe their child issues (stories and tasks); you can also manage Epics through your workflows. This allows you to measure issues that are all related by a common theme — the Epic Name. Since Epics are issue types, they can be created by anyone who has the create issues permission for the project.

Components are a great way to create sections within a project. You can use them to align issues within a project that share common technologies or feature sets, like User Database or eCommerce. A very nice feature of Components is the ability to set a default assignee for a particular Component type. This helps to self-manage work and highlight the person who is the Component lead. For example, Mike is an expert on GraphQL, so we use Jira to auto assign all issues with the GraphQL component to Mike. Components can be added as your project permissions are established. Typically they are entered by a Jira or Project admin.

Labels, as the name implies, can be thought of as a tag or keywords. They add flexibility by allowing you to align issues that are not under the same Epic or Story. Anyone can add labels to an issue, as long as the label field is available in the issue. They can be selected from a predictive list if one or more is already in use. Where components are a structured grouping, Labels are more of a free association that can be used by anyone for any purpose and allow for simple querying and reporting. Some examples you might use could be: needs review, ready for UAT, or MVP.

Visualization and Use

Sample hierarchy view showing different features in use:

Like any tool, they can be misused or misunderstood. However, when used correctly, they do a great job for what they are intended. Epics are a centerpiece of Jira. Used to gather information, track progress and generally share information. As a Project lead, it is important to keep that center in balance. With that, team members can be confident that an Epic will share with them relevant information for the Story or task they are working on. One of their best uses and something you as a Project lead should do is to contribute project information using Epics. As a reporting piece, Epics reflect a high-level progress view and allow for the planning of project roadmaps.

Pitfalls

Teams and managers can get into a little trouble if no one properly manages the use of these Jira features. Somethings I quickly learned and did not easily forget was encouraging team members to store information with Epics. Keep conversations specific to the work in the issue itself. It is easy to lose information from an email. Make sure relevant work is a child of its Epic or that the Label, Component or the relationship (Linked Issues) is being used to reflect correlation among issues.

• Epic
  • Using as a release or a milestone. Jira has a feature of a release or fix version. Delivering all the items for an Epic for a release is great. However, it is common for some items to be released for the Epic while other items are released at a later date — most likely a future release under a new Epic.
  • Creating related issues outside the Epic. Issues not captured in an Epic do not reflect a relationship. The issue may not be released as expected, or it won’t be captured in reporting and will fall outside your monitoring tools.
  • Putting Epics in a sprint. While this isn’t horrible, the general idea is that an Epic contains a series of issue types or work, that is to be done. Your team delivers on items within the Epic; they are not necessarily themselves a deliverable.
• Component
  • Vaguely describing Components. Too often someone will create DB as a component when a more descriptive name would help a lot. For example, User DB clarifies what component is actually being used.
  • Creating too many Components. Doing this can make assigning work confusing. Be mindful of the Components being used and create them so all areas are covered, but try not to overuse them. Fifty components are too many to choose from. Instead, try to stay within 15–20 for a project, depending on the size of your project.
  • By default, the Component Lead is also the Project Lead for all Components. The Project Admin can update to an appropriate role as needed.
• Label
  • Creating numerous spelling, capitalization, or grammar variations:
    • Login vs. login
    • User vs. user
    • Database vs. DB
  • Using poor abbreviations. As mentioned above, abbreviating can cause problems. It is better to spell out Database than use DB. An example that caused headaches for me – there was a project, that abbreviated, was SOP and there were also documents that were SOP (standard operating procedure) items. Neither was aware of the Label inadvertently being used for both but later noticed issues being pulled in queries where they shouldn’t be. Use abbreviations sparingly and be thoughtful of their use. If you must abbreviate, make sure the abbreviation is widely understood by your team.
  • Creating too many labels. Managing a large list of labels is almost impossible. For example, if you cross use many labels you’ll find it difficult to efficiently query and monitor.

Conclusion

All three of these Jira features are a fantastic way to manage, monitor, and report on work being done in your project. The rules you establish for their use must be adhered to for them to work effectively. Worse than that, if a single person does not follow the guidelines established, items can be overlooked or obscured from your goals, monitoring the momentum of work, and reporting progress to your stakeholders. Be thoughtful and vigilant in their use and they will in turn help in capturing critical details for successful product delivery.