I have used JIRA for something like 5 years now. I am a big fan, in that it is definitely the best issue tracking solution out there. However I’m also quite critical of it at times, because I think it often fails in usability and UI terms to deliver an intuitive experience for those doing software (and particularly web) development.

So I thought I’d write some initial views on the Jira 4 UI and GreenHopper – my hope being that GreenHopper will alleviate some of my release planning frustrations with Out-of-the-box Jira. These are most definitely first impressions. Any major UI changes are likely to be met by resistance by seasoned users of any application.

First, the good:

• Jira’s main dashboard UI etc looks cleaner, drop-down menus for quickly getting to specific projects are welcome
• The whole thing feels less cluttered because the right hand side bar which, in my experience was almost never used by most JIRA users, has been taken away
• The drop-down action menu for each result in an issue navigator search is great
• The activity stream stuff is very helpful

Now, the contentious core JIRA stuff:

• I now feel like I have no issues. If only it were true. The whole JIRA UI feels “too” sparse, I feel like I cannot see my workload properly any more / the status of the project. A prime example is when you click on a project version and are shown the version summary tab which seems to show at max 3 updated + 3 “Due” issues. What use is that? Doesn’t seem configurable. UPDATE: Brian Lane, JIRA product manager has told me this is configurable in a configuration file but not in the UI, where the setting jira.project.summary.max.issues=3 can be found.
• Roadmap view – for me at least – is completely useless now. It no longer shows all issues for a version if there are “too many”. This should at least be configurable and behave like old Jira by default. Its an imperfect world. Some of us have 170 issues in a version What’s more the issues are sorted obscurely – you’d assume if only showing 50 issues it would show the 30 unresolved issues, but for me shows about 8 of those and 40+ resolved ones. Roadmap does not show me my roadmap, I have to drop into issue navigator
• I hate portlets. For dashboard overview stuff, fine – but they are used in other places too eg project overview, which feel like UI/usability cop-out. Its not Web 2.0, its iGoogle. Portlets are too generic to make any app feel seamless.
• “advanced” searching with some new Jira QL is enabled by default it seems, which I think is a mistake. Bring back the good old simple search for most users by default. UPDATE: Brian Lane also told me that this is not the case, it is not on by default. I don’t know how it became on for me though.

Next, my first impressions of GreenHopper:

• GreenHopper is very specific to a particular Agile methodology and “card” (or post-it) metaphor. This IMO is enough to make it a total WTF for any users who are not Agile Scrumbag 3rd Dan Blackbelt Extremists. That includes me.
• I was hoping for drag and drop planning of issues eg assigning them to people and versions in the roadmap. This is there, to a degree. GreenHopper is major overkill for the majority of users – and yet with no DnD scheduling in core Jira, you have little choice if you want to avoid the horribly repetitious standard Jira workflow steps to change fix-for on issues during planning where batch changes are not that workable as they require scanning all the issues before making your changes.
• The UI is highly functional for the specific metaphor and methodology, but is frankly insane for every day users. It makes me feel ill trying to using it. Too much colour. Too many options. Too small fonts. Web 2.0 was years ago, we’re allowed to use a font > 12px high now you know!

Things I want day to day but can’t seem to achieve even with the power of Greenhopper and Jira 4:

• Drag issues to become subtasks of a parent
• See a “tree” of issues as a list eg parent issues with subtask issues shown below them
• Get an instant view of how close we are to the top-level features (parent tasks) being completed – eg the red/green bar of subtask completion for all parent tasks, shown in a flat list. Don’t get me started on the “Task board” of GreenHopper. Powerful yes. For mortals? No way.
• JIRA completely lacks the personal element commonly found in Web 2.0 apps – avatars for user accounts. Github has this, so do most other hosted web 2.0 apps. Its a real omission and means functionality like “drop issue onto user’s face to assign it” is not yet possible.

JIRA is very powerful, has had some solid UI improvements, but ultimately I think from a web-app developer’s point of view it is now weakened by its un-opinionated and excessively generic underpinnings. This can be seen by the way GreenHopper had to shoehorn its way into JIRA UI with some truly ugly configuration screens, mismatched fonts, general lack of integrated look and feel – and popup windows with standard Jira issue edit screens in.

It feels like JIRA is still firmly rooted in the waterfall-approach era. It has been very successful by trying to please everybody, but I feel that it is not yet up to the task of truly excellent web-development tracking – although it certainly remains the best option out there at this time in my opinion.

The GreenHopper plugin tries to bring a visual metaphor to all this, and that is welcome. However I think the visual metaphor of just dragging issues in the normal JIRA roadmap view would work a lot better for 90% of users than the agile “card” approach and all the steroids that those UI screens have been given.

I hope this doesn’t come across as too negative. Both products are a move in the right direction and there’s no way you can do wrong with the currently special offer pricing that’s for sure.

However I hoped for a bit more progress in Jira’s UI for release planning etc out of the box - I wrote about these desires way back in 2006 - and GreenHopper despite normally being a premium product for exactly this, in my opinion fails to meet the needs of real-world users (eg the ones who don’t live in an Agile methodology bubble).

Anyway I decided to finally put the things that I nag my colleagues about into a set of hopefully useful basic tips for using JIRA effectively. I really am a JIRA obsessive at times…

TIP #1. When creating a new issue, think about the people interested in the issue.

JIRA almost exclusively uses the issue summary when displaying lists of issues, be they reports, portlets, Changelog or Roadmap. Therefore what you write in your Issue Summary is vital. It must be ubambiguous, clear and concise. Here are some real world summaries for issues I’ve been assigned, which do not meet the above criteria:

"Home page – title"
"Documentation"
"punctuation in a search term"

The only rational response to those is "Yeah, what about it?!" until you dig into the issue to view the description. See how they look in a dummy changelog scenario:

Release Notes - PROJECT XXX - Version 1.0

** Bug

    * [XXX-1] - punctuation in a search term

** Improvement

    * [XXX-2] - Home page - title

** Task

    * [XXX-3] - Documentation

Not exactly informative is it? Users/stakeholders will not really understand what has changed in this version.

Issue summaries should be concrete statements of problems or tasks, such that the changes effected in the behaviour of the project resulting from them is pretty obvious to the reader. We might re-write the above issues as:

"Change home page title text"
"Create new developer documentation"
"Punctuation handled incorrectly in search terms"

Much better, and it all looks much more professional too, vital for any public-facing project.

One common reason for vague summaries is creation of high level "macro" issues by an individual who does not understand the underlying tasks required to resolve the issue, which leads us onto the next tip…

TIP #2. Raise high-level requirements as issues, and use sub-tasks to structure the action required

If you are lucky enough to have JIRA Enterprise, you have the fantastic sub-task feature. It is a great shame Atlassian do not offer this in all versions as I think it is pivotal to effective JIRA usage, and the price differential between Standard and Enterprise is far too much if you just want sub-tasks and not the other enterprise features.

Rant-over, here is a typical usage scenario – Manager wants a new feature "Make widgets support Foo".

As a standalone issue this is annoying for developers as they have to edit it to make it apply to the underlying tasks or create new issues and, very clumsily, link them in to the original with issue linking. Still the relationship between the issues is not very visible.

The solution is for the people assigned to the issue to create sub-tasks of the issue breaking it down into the "technical" details of the job at hand.  Everybody can then see the status of the high level task in terms of its underlying tasks. See this example of such an issue

What’s even smarter is that high level tasks and sub-tasks do not need to share fix-for versions… which means you can pencil in your major functionality for release 1.0 but fix portions of it and release them in point releases 0.5, 0.6 and so on and only in final 1.0 release is the entire high-level task complete.

Anyway we have a couple of gripes about this:

1. Exported iCAL files always include issues even if you set issue count to zero in the portlet. I wonder if there Is a param to add to limit number of issues in the iCAL feed?
2. For the calendar portlet to be useful in the context of a filter handling many projects, you are forced to truncate your project version names to only include the number. This is ok as you can put descriptive text in the Description field of a version… BUT when you see affects/fix-for version list boxes when creating an issue it doesn’t show the description so Joe Bloggs in management says to me "Marc – where have all my version names gone, I don’t know if this issue should be fix for 2.0.2, 2.0.3 or 2.0.5 because I can’t see the info relating to the version any more".

I suppose with the latter, we need a way to either have the version list boxes show description also (maybe via a little ajax/JS panel?), or some kind of config for the calendar plugin to tell it stop parsing the version name property when it meets a certain character. Neither is very nice.

The problem is that the calendar plugin is potentially useful for us to keep abreast of what we have to achieve in the month in terms of version releases, but to do that means making issue creating much more error prone and confusing for those people who can’t remember exactly what each version number relates to on our project roadmaps.

on run
  using terms from application "http://somefakedomain"
    tell application "http://yourjiraserver/rpc/soap/jirasoapservice-v2"
      set loginToken to
          call soap {method name:"login",
           parameters:{ username:"youruser",
            |password|:"yourpassword"}}
      set remoteIssue to {project:"PROJECTKEYHERE",
        type:"1", summary:"",
        assignee:"yourassigneehere"}
      set summary of remoteIssue to
        "Testing creating issue"
      set createdIssue to call soap {
        method name:"createIssue",
        parameters:{token:loginToken, issue:remoteIssue}}
      log "Create issue " & createdIssue
    end tell
  end using terms from
end run

When this happens I have to use “Bulk change” in Jira’s issue navigator to locate the subset of issues that are going to be “bumped” and change their Fix-for version to the next version.

However sometimes we need a new version inbetween the current and next, to handle those “bumped” issues. i.e. version 1.0.14 was going to have X and Y in it, and 1.0.15 is going to have P and Q in it. After bailing out issues that can’t be fixed for 1.0.14 we really need 1.0.15 et al to be moved up a revision number (to become 1.0.16 containing P and Q and so on), and a new 1.0.15 created containing just the issues bailed out from 1.0.14.

Because Jira is not version-number aware currently, it cannot do this. It could currently offer a “Split version” option in the Version Management page, so you could instead of Releasing make it “Split” the version into resolved and unresolved issues, and prompt for a new version number to sit in between this and the next release. So we could enter “1.0.14b” for example.

It’s not perfect – auto version numbering would be much better – but it would do until that comes.

1. You need to be able to “Send this portlet” to another user, and have it send them the required filter also if it is not a global shared filter.
2. They really need email announcements when versions are released, and allow users to “watch” projects to receive these emails.
3. Users should be able to choose only the projects they are concerned with. For example on jira.codehaus.org there are loads of projects and as a “privileged” user there I can see all of them, but that sucks. True this could be done with permissions but that means 1 permission scheme per project, and even then I might work on only 5 projects today, but a couple more next week. The project pop ups are therefore extremely overloaded for me.

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.