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.
March 12th, 2007 at 4:16 am
I totally agree that Sub-task is an important feature and should be available in other version of Jira as well. Currently, I am using Jira Standard version and I have to use Issue Linking feature to implement sub task functionality.
March 20th, 2007 at 7:11 pm
Two comments:
1) JIRA pro allows sub-tasks.
2) Regarding tip#2; because JIRA doesn’t allow infinite levels of subtasks, it was suggested to me that we use a project that I now call “Requests” that store business-language requests in and a sister project called “Development” is used for the actual work to solve those requests. I name the projects “x requests” and “x development” (where x is your app name). Into the Requests project are things like “Make the application faster”. When the it is decided to have the dev team address the issue, like you said, many enhancements can be created to solve one request. I then use the sub-tasks to track things like acceptance tests for that particular enhancement, and documentation tasks to make sure help files and manuals are kept up to date (I can reconcile that each enhancement is documented). This approach does two things: 1- Allows users to request things in their own language and 2- keeps the development project “clean”. before we implemented this approach, we’d have hundreds, or thousands of unscheduled requests and that is depressing for development. Now the unscheduled requests are in the business owner’s project and it is up to them to prioritize.
March 23rd, 2007 at 5:16 pm
Well that’s good news - has that changed? As far as I recall sub-tasks were only in the Enterprise version in the past. I may be wrong.
Re: 2) Do you link the high level request to the development high-level task, i.e. to track when a client task has now been completed, and in which version? Manualy linking in Jira is very painful IMO.
April 19th, 2007 at 11:23 am
Is their a way to relate the version number of the sub-task to that of the parent? For example we can’t have the parent fix ship in 1.0 if the sub-task does not ship until 1.1. Does JIRA enforce/highlight this or do I have to keep them in sync manually?
April 19th, 2007 at 3:16 pm
No it doesn’t do it. You can almost certainly write a plugin to do this but I would recommend contacting Atlassian and asking for this feature. However this is in part down to how you use Jira. Really it should stop you setting fix-for in this contradictory way. It should also offer to automatically close/resolve the parent issue when the last sub-task has been resolved
Oh, and it should have the option to exclude sub-tasks from Release Notes
March 11th, 2008 at 7:41 pm
I love the sub-task feature. I’d like to take it to the next level - subtasks of subtasks. Change Request is the high-level issue; Requirements are the sub-tasks - and I’d like to have test cases be the sub-tasks of the Requirements. Any ideas?