Atlassian JIRA 4 and Greenhopper – First look

I recently upgraded our JIRA instance to version 4 and installed the GreenHopper plugin – after getting them for the bargain price of $10 as part of Atlassian’s amazing repeat bargain offers for charity. I can’t recommend this enough – $10 for enterprise Jira is amazing.

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).

Using JIRA effectively #1

I use on average 3 or more JIRA instances per day on different projects, and have used Atlassian JIRA now for what must be at least four years now. I ask every prospective client I meet whether or not they have issue tracking yet and if not I recommend JIRA. It is a fair observation however that if they do answer no, it is often a clear sign that the project lacks effective project management, which is usually something that a JIRA license can’t solve, although it can make it more bearable.

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.

Jira Calendar Plugin and version naming issues

We just discovered the great Atlassian Calendar plugin. We have our calendars exporting to Apple iCal and we’re all very excited about how this allows us to plan our time in relation to all the projects and releases we work on (we do a bunch of websites and there’s always a lot going on).

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.

Creating JIRA issues with AppleScript

I just played around today and got this quick AppleScript JIRA SOAP hack going. AppleScript is much maligned, but its very easy to get some things go. Sometimes it does "just work".

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