Relation and nature of releases, components, epics and labels

[Phil Newby]

Hello

I've been using Jira for about 4 months now as a new user. Currently my workplace has been using Jira for well over 3 years and as such it is quite a mess.

The QA manager and I are looking to try and improve the Jira tools we use at the company because currently we are only using epics and labels. Which had led to us having 46 epics and 51 labels in total - all of which are usually very specific to projects that have been archived years ago.

For context, I work at a small software startup (yes its an app company how could you tell?) which means there's a big emphasis on not only providing information for reporting and managers but also for developers to simply get in, do their tickets and get out with minimum hassle, currently we are struggling to do the former.

The aim of this new system is to create a better method for generating reports for management while giving developers the needed information to do their jobs. But the main point is to have the system be relatively self maintaining and scalable.

I have done some research on releases, components, epics and labels but I am struggling to figure out which heads should belong under what tool.

Here is my current proposed system, which isn't set in stone;

Releases (features)
Security
Registration
Push notifications
UI/UX design
Testing
etc.

Components (point of management)
Project manager

Epics (platform)
Web
App
CRM

Labels (area)
MVP
Not MVP
Frontend
Backend

Could anyone please share with me their experiences of managing Jira and generating reports? What systems have worked out well and why? Feel free to pick apart my above proposal.

Thanks in advance!

[Oliver Siebenmarck _Polymetis Apps_ · Accepted solution]

Hi @Phil Newby ,

Welcome to the community!

As you might already know, each team organizes their Jira differently, so there are no right or wrong answers. So take the following as opinion rather than fact.

Releases are meant to be used for shippable versions of your app/software, so they typically would have names like: v1.0.2, v2.3.4. Releases also do have start and end dates, so it makes sense to plan them on a timeline. I would not use releases to plan features.

We have used components for both – specific parts of an application (Frontend, Backend, Database) as well as complete apps. It does depend on how you organize your teams and projects, but the way you described it, I would use components for your platform (like you wanted with the Epics):

• Web
• App 
• CRM

Epics on the other hand, we usually use as features or a collection of closely related features; what you had under releases, we likely would've put into epics.

Labels are one of my favorite features in Jira (and Confluence!) – you can use them for virtually everything. There seem to be two schools of thought when it comes to label use.

One favours the free-for-all approach, where a label is applied whenever a team member believes it fits – with minimal oversight. This makes sure that you do not miss any important information because it does not fit into a pre-defined category. The downside is the seemingly inevitable label sprawl that you have also seen. Still, I like this approach. 

The other approach to labels is to pre-define allowable options and make sure that only correct labels are used - typically using workflow validators. Or you could just use multi-select custom fields with your favorite options.

From your examples, I'd turn MVP/Not-MVP into release versions and would either try to fit Frontend/Backend into the application components or in fact use labels.

Finally, if out-of-the-box Jira does not quite do what you need it to, there's the Marketplace, which has a wealth of apps that improve upon Jira in various ways. In your case, I would recommend the following, only the one of which is offered by my company: 

1. Swanly is a fantastic tool for roadmaps and release planning. It is definitely worth taking a look, especially when working across multiple projects.
2. Project Labels allows you to take a more active approach to managing your labels in Jira. You get an overview of all labels used in your projects, along with bulk actions (like fixing a commonly misspelled label), but you also get a label field with pre-definable options on the project level, ie. project admins can define options for their project. I work for the company that builds this app.

So, this got a lot longer than I thought. I really hope this helps and let us know which way you went!

Cheers,
 Oliver

[Phil Newby]

Hello and thank you 

I've had a look into the above and it looks good so far, i'll continue to tweak and play around with it!

Thanks again!