In Jira, Programming links

Jira issue tracking meets tagging

Posted by: on Jul 27, 2006 | 4 Comments

I just had a brainwave. For a little while I’ve been wondering about how ineffectual setting the Component seems to be in Jira. Many end users don’t know what component the issue affects, initial assessment is often wrong, and most of the time it just feels like you are entering data for data’s sake:

Add to that the fact that Jira does not support per-component versioning (AKA truly nested projects) and Component seems pretty redundant; it can only used in searches or in the Open Issues tab to break down by component.

With the popularity of tagging in applications like Flickr, iPhoto, delicious etc I wondered if this might work better for grouping issues.

Also I’ve recently been working with a client for whom I have setup all the initial tasks we have but I need them to prioritise them for me so that I can tackle the most important ones first in a series of incremental code builds. Changing the issue priority is a coarse way of doing this – I want to schedule these into different release versions in the roadmap, and have sensible priorities on them within each version. Also, if I re-edit the priority later I lose the information that the client provided about the importance of this issue to them.
I realised that tagging would help here. Tags like “must have”, “very desirable” and “wish list” are concepts that people can relate to, and allow me to preserve issue priority information (which applies per release rather than globally).

I thought of adding a custom field as Jira has great support for these, and includes them in searches etc. However it might be a bit too loose – my clients may not know what tags to type in, spell them wrong etc and we end up with a mess.

Then I realised. Component field settings ARE tagging but with the wrong name. I’m going to set up “components” (in Jira parlance) for “Must have”, “Very desirable”, “Wishlist” as well as other non-priority terms like “Web”, “Search”, “Content”, “Browser compatibility”. These are not strictly components at all but if you look beyond the name you can get exactly what you want – and even better, the Open Issues tab will now show me how many “Must have” issues there are etc – and provide links to view lists of them so that I can review them, bulk change, and assign them to versions in my roadmap.

We can’t rename the Component/s field to “Tags” in Jira – maybe they will do it for us in future… but for now in Jira setup (Issue Fields) we can at least change the description to explain the tags concept to the end users.

4 Comments

  1. Michal Szklanowski
    July 27, 2006

    Hi,

    I’m also a hardcore JIRA user and evangelist in my company. I tend not to agree with what you have written here. Using components to support other way of prioritization or so-called client-side prioritization (how important is this feature for the client) is generally ok, but renaming them to ‘tags’ is a little bit of exaggeration.

    Tags (folksonomy) are defined as collaboratively defined vocabulary of keyword, while your approach is really to create another taxonomy (controlled vocabulary) that client can use to prioritize items from his side.

    Going back to real tags, I found Label plugin very useful in JIRA. We use labelling for example to mark cross projects issues that are somehow related to some separate development spanning many projects/platforms. Before we installed Label plugin there was no logical way how to group those issues together apart from linking them, which is then very cumbersome when it comes to seeing all the issues related, and not only the nearest one.

    Reply
  2. Jon Silvers
    August 2, 2006

    Thanks for the comments, Marc, I’ve also reposted it to our site — some good suggestions here that other users could benefit from.

    Reply
  3. Marc Palmer
    August 23, 2006

    Michal – yes I know its not quite the same tagging, but it is more like tagging than Component(s) and the component mechanism has not been very useful to me at all on any projects. We have components, and people put this data in, but nobody I know really does any component based reports.

    Because Jira lacks versioning per component, you have to use a project per versionable component – many applications are not discrete and have dependencies on other internal components. As such component is therefore largely redundant and in my opinion better used to “tag” issues into one or more categories.

    Being able to fix these is useful in an issue tracking environment because in reality a lot of the users to not understand what tags to use if they are not shown the tags they can choose from.

    Reply
  4. Terry Laschuk
    February 27, 2009

    In my company we use the component field to identify different scrum teams within a project.

    Couple that with individual sprint versions and we have a workable system for multi-scrum, multi-sprint projects.

    I think the ranking field should be used by the client to rank order the stories and then you use the priority field to order the tasks (critical, major, minor).

    The Must Dos are what are on your sprint backlog and taken from the product backlog. Usually in the order of the ranking given by the product owner.

    Reply

Leave a Reply