Jira and GreenHopper for agile project management

by Brad on December 17, 2009

I previously blogged about using Jira with some open source tools for managing agile projects, and concluded that it was not a great solution – without GreenHopper. I’ve been using the latest version of Jira with the GreenHopper agile plugin extensively now, and I like it. It is lacking some features, which I’ll describe later, but here is an overview of the main functionality.

The first thing I like is the Planning Board view, which is aimed at Product Owners who spend lots of time ranking and re-ranking backlog items. The GreenHopper planning board allows you to drag and drop items to either change their rank or to move them from the backlog into a particular iteration or sprint (version, in Jira lingo).

Above: dragging a user story from the backlog to a sprint. (Click image to see it full-size.)

For the development team, GreenHopper’s Task Board view is just that – it simulates the physical task board that so many co-located teams use. It’s easy to drag the virtual cards to columns to update their status, just like you would do with a physical board. Very nice. It also does something you can’t quite do with sticky notes; double click to see more information, or click on the item ID to see all the detail.

Above: The Task Board in summary view mode (Click image to see it full-size.)
Above: See more of the task board without scrolling – the List view (Click image to see it full-size.)

Above: Dragging a card from “To Do” to “In Progress”

Above: Double click to see this expanded view of any card on the board.

An advantage of GreenHopper over sticky notes on the wall is that your burn down charts are calculated automatically: in hours, number of items, and story points. The screen images below show these. The red line is the ideal burn down and the green line is the actual.

Above: Burn down in hours (Click image to see it full-size.)

Are you a bleeding-edge adopter of kanban? GreenHopper is decent for that. The columns on your kanban board are customizable, so you can create any columns you want. You can also set a WIP limit for each column. You can’t, however, set up horizontal “swim lanes” for different service level agreements (SLAs), such as a row for items that need to be expedited.

Above: The column turns red when the WIP limit is exceeded

The Jira dashboard also offers a reasonable approximation of the cumulative flow diagram (CFD) that replaces burn downs in a lean / kanban process. It does show items created vs. resolved, but it doesn’t graph items in-progress. The chart also counts sub-tasks as items, which you may not want.

Above: Almost a cumulative flow diagram. Close, but no cigar.

GreenHopper is an add-in to Jira, so you still get all of the Jira functionality unchanged. Like Jira itself, GreenHopper is extensively configurable; almost annoyingly so because there are so many options it’s hard to know what to do with them. Fortunately the default configuration is reasonable, although there are some setup steps required to enable item ranking, which is so fundamental that it should have been done out-of-the-box.

What is it lacking?

  1. If you’re a large organization with a portfolio of inter-related projects, Jira + GH doesn’t do much to show you the big picture across multiple projects.
  2. Although you have a hierarchy of versions, such as a release containing multiple sprints (described here), it doesn’t do much; the planning board simply indicates that one version is a “master” of the other. GreenHopper doesn’t offer a timeline view showing the version hierarchy.
  3. You can create a hierarchy of backlog items, for example to have large-scale epics that contain many user stories, as described here. However, this feature isn’t enabled by default and requires an adminstrator to configure it. As an alternative, or in addition to the “epic” feature, you can create associations between items for this purpose, but there is no easy way to visualize the relationships. There is free task hierarchy plug-in that will show the hierarchy, but only for one top-level item at a time. 

Overall, especially for smaller teams without portfolio management needs, I give the tool high marks.

{ 24 comments… read them below or add one }

emachado December 18, 2009 at 1:48 pm

What I'm missing in a JIRA+GH enviroment is a way to get customers to write their own User Stories. Any advice on how to do this using another tool if needed.

Bob Hartman December 18, 2009 at 2:23 pm

Brad, you've now reviewed a number of tools. For an enterprise with 10 teams and multiple projects in a portfolio what do you recommend? Keeping in mind the need for some simple Kanban stuff as well as more in depth portfolio management.

- Bob -

Brad Swanson December 19, 2009 at 12:35 pm

Regarding emachado's question: Do your customers have access to Jira? Are they internal or external customers? For internal customers with access to Jira, you would need to educate them on how to write good user stories, and then I would create a Jira version called "requests" where those could be analyzed and ranked by the product owner. For external customers, you _may_ be able to setup Jira roles and security in a way that gives them access to make requests and report bugs but nothing else; I don't know for sure if Jira supports that, though. You could certainly host a separate Jira instance, or other ticket tracking system for external customers, and import those items into your internal Jira backlog. Good luck teaching external customers to write good user stories, though!

Brad Swanson December 19, 2009 at 12:46 pm

For large organizations with a need for portfolio management, Rally Enterprise and VersionOne enterprise have rich feature sets for multi-project portfolios, although I don't have much experience using them myself. I intend to dig deeper into those two to learn more.

Jira simply doesn't support cross-product feature hierarchies, roadmap planning and portfolio planning IMO.

I compared some open source tools in this article. Among these, AgileFant probably fares the best for portfolio management but the lack of "Epics" (feature hierarchies) is a serious limitation. IceScrum has some features for large organizations but still is lacking in others.

emachado December 22, 2009 at 2:41 am

Thanks a lot for you reply.

I'm talking about internal users, we have to educate them on the use of JIRA anyway(as we are using it for incident tracking), but the problem is that I find JIRA+GH too complicate for simple User Stories writing, maybe creating a simplified client of JIRA with a basic layout could be developed, or just using a different tool. But I'm also worried about duplicating functionality.

Brad Swanson December 24, 2009 at 10:49 am

What specifically do you find too complicated? In my opinion, it's easy to create a new user story in Jira. Just click the "Create new issue" button and go! The fields to fill in are easy to understand. You can also use the "New Card" button on the planning board view, which shows fewer fields and might be easier to learn.

Larry Talley April 1, 2010 at 10:24 am

We have recently enabled email submission to JIRA, and this has really accelerated the use of JIRA by non-programmers in our organization. Everyone knows how to send an email.

Of course we have to do some management of the issues that get created in this way. Some aren’t well expressed, they all need to get moved into the right projects, they need triage/prioritization, categorization, often follow-up for more detail.

But, it does let non-programmers easily create an issue, and then gives our technical folks a framework for follow-up and refinement of the problem statement.

Many of the issues the users create do turn into stories… although we almost always have to edit them before they are recognizable as such.

Arun April 5, 2010 at 10:11 pm

Hi,

We are using story-points with JIRA. One of difficult task that we are facing is regarding work-flow.

We typically divide User-story into number of tasks. Couple of tasks for analysis and development and one task for testing the whole story. As soon, developer fix the issue, he/she set the tasks as resolve and inform Tester (through mail), that story is ready for testing.
Now we are facing problem,
1. If somehow, tester did not finish testing user-story in associated sprint, it affect burn-down chart of developer also, since story is originally assigned to developer, with one task inside it for tester.

2. How developer communicate to tester about testing of user-story, if we do not use email option.

3. I want to know, if it is right approach? If not what is possible solution.

Thanks

Arun Sharma

Brad April 6, 2010 at 1:36 am

Hello Arun,
Jira has a “watch” feature that allows users to subscribe to changes on an item. In your case, the tester could “watch” the user story and/or the developer’s task item in Jira and receive notification from jira whenever the item is finished. Is your team co-located in the same office? If so, I prefer face-to-face communication between programmer and tester – this is one of the 12 fundamental principles of agile development.

As for the burn down, I do not use individual burn down charts, only team burn down charts. Scrum describes a burn-down chart only for the whole team, because it’s only the work of the whole team that matters for delivering value to customers. This is intentional because we want scrum teams to act as true teams, where everyone succeeds or fails together as a team.

Brad April 6, 2010 at 1:36 am

Hello Arun,
Jira has a “watch” feature that allows users to subscribe to changes on an item. In your case, the tester could “watch” the user story and/or the developer’s task item in Jira and receive notification from jira whenever the item is finished. Is your team co-located in the same office? If so, I prefer face-to-face communication between programmer and tester – this is one of the 12 fundamental principles of agile development.

As for the burn down, I do not use individual burn down charts, only team burn down charts. Scrum describes a burn-down chart only for the whole team, because it’s only the work of the whole team that matters for delivering value to customers. This is intentional because we want scrum teams to act as true teams, where everyone succeeds or fails together as a team.

Arun April 6, 2010 at 3:10 am

Hi Brad,

Thanks for prompt reply. You answer most of my queries.

Our team is distributed across continents, so I think, “watch” feature is useful.

I agree with you, that burn-down chart of Team as a whole should be considered and taken care of.

There is supplementary questions to my First question. In case, If developer resolved all their tasks, but tester did not find time to test the user-story in given Sprint, then

1. User-story stands unresolved for that particular sprint, right?
2. What is the status of developer’s task, they are in “resolve” status or “closed status”?
3. The overall status of user-story is “in-progress” right?

Thanks once again.

Arun Sharma

Brad April 11, 2010 at 4:29 pm

Arun,
You are correct that if a story isn’t completely done, it should still be in progress. I normally use “resolved” for tasks to say that the individual developer finished it, and “closed” means that the entire story was accepted by the product owner. You can decide on your own definition for “closed” status.

Arun April 13, 2010 at 4:03 am

JIRA, EPIC and Story-point:

Hi Brad,

I am again knocking your door for answer to my next question of agile development with JIRA. I am currently working on large epic. I can’t estimate it. I am planning to have 5-6 User Stories linked to this epic. Each user-story is further divided into tasks ( which I can estimate in hours).

My question is regarding linking User- Stories to epic in JIRA. I am unable to find any way to link epic with user-story. I am using JIRA version 4.0.

Thanks in advance for your help.

Regards,

Arun Sharma

Brad April 13, 2010 at 8:15 am

Hi Arun,
See my point #3 in the last paragraph in the post. It can be done, but it’s not a great solution.

Jose May 5, 2010 at 11:19 pm

Hi,

We face the same dilemma, where we have multiple teams working for the same Program, although some are 100% allocated to that Project, others are Support (like my team) or Testing that have some allocation to that particular project (and many others) also require some way to manage their own work, sort-of having the direct clients in Jira in their own project (like defining the top level requirements of features).

The way I thought this would be possible would be to have a hierarchy of issues (Epic > Story > [Task > Sub-task]) that would allow to place the top level issues as close as possible in the Client related project, so that it could have visibility over all open sub-issues (and their children).

Not having an easy way to create these associations besides linking and labeling really is a show-stopper.
Do you know if it is possible to implement a custom work-flow that contemplates this hierarchy of issues ?

Regards,
José

Brad May 6, 2010 at 7:31 am

I’m not aware of a work flow that would solve this. You’re right that linking can be used for this, but not very easily. This is one my biggest complaints about Jira + GH. The best solution I’ve found is described here: http://confluence.atlassian.com/display/GH/Working+with+Epics

Lawrence Ong August 19, 2010 at 5:21 am

Hi Brad,

I have a question regarding Jira+GH. Recently installed it and am working through migration from Mantis.

Where would be the best place to set up standard tasks for every project/release, such as prepare deployment document, setting up project charger… in other words, non-developer type tasks but nonetheless important to track?

Along that vein, how would I go about creating a PM template, such that for every project or release/version we create, that these tasks simply get created as well?

thanks for your time.

thanks,
Lawrence

Brad August 19, 2010 at 12:40 pm

Lawrence,
I’m not aware of a way to do those things in Jira, and a quick search of the the user and admin guides didn’t reveal anything either. You certainly can create custom task types (for example a “documentation” task) which can have custom fields and even custom workflows. You might be able to use the Jira APIs, SOAP or XML-RPC interfaces to build something that would create those standard tasks, or maybe clone another project. Sorry I couldn’t be more help.

Lawrence Ong August 19, 2010 at 3:24 pm

Hi Brad,

Thanks for your reply — I looked into JSS which may perform some of the automation tasks – although from what I can tell it looks like a stitch-job.

But, I think there’s a fundamental issue here — The tasks which are created for the purpose of managing a project, usually do not follow the standard status/resolution codes set up for Issues/Features. For example, a task called Prepare Pre-Release Document, isn’t “resolved” when it’s completed — there doesn’t seem to be a way to create a subset of values for status/resolution based on the type of task…

I think this should sit outside of Jira/Greenhopper, but I’m not sure which application can work with JIRA in this manner.

What I’ve come up with is confluence — a wiki which uses a dynamic task list to check for users to check off when the item is completed. However, if the person completing apre-release document is the same person managing the tickets via Jira/Gh (which I think is the function of a product owner), then he or she has to look at 2 lists, further complicating the process.

If my use-case(s) is very different from others, perhaps you can shed light on how these are tackled in different organizations.

thanks,
Lawrence

Brad August 24, 2010 at 2:54 am

Lawrence,
Confluence is a great tool to supplement Jira. If you have tasks that really don’t fit into the same workflow as development items, then tracking those in confluence might be a good solution. However, if writing the “pre-release document” is work to be done by the team, then it might be better to track it in Jira along with all the rest of the team’s work – their _single_ backlog. And yes, a document might not be “resolved”, but at some point it needs to be “done”, so you can agree as a team that for documents, the “resolved” workflow state means that the doc is completed, and perhaps also reviewed or approved.

Janis Workman December 23, 2010 at 5:10 pm

JIRA, EPIC and Story-point: Hi Brad, I am again knocking your door for answer to my next question of agile development with JIRA. I am currently working on large epic. I can’t estimate it. I am planning to have 5-6 User Stories linked to this epic. Each user-story is further divided into tasks ( which I can estimate in hours). My question is regarding linking User- Stories to epic in JIRA. I am unable to find any way to link epic with user-story. I am using JIRA version 4.0. Thanks in advance for your help. Regards, Arun Sharma

Brad December 28, 2010 at 2:05 pm

Jira/GH 4.2 (and I think also 4.0 and 4.1) has an “epic” field that is of type “label”. You may need an administrator to enable this field and make it visible for your project. Once it’s there, you can assign the same label name, in the “epic” field, to all stories that are included in that epic – and to the Epic Jira item itself. Now if you include the “epic” field in the Jira/GH cards layout, you can click on the “epic” label for one card and Jira will show all other items with the same “epic” label.
See here for more info: http://confluence.atlassian.com/display/GH/Working+with+Epics

joel April 10, 2014 at 4:29 pm

Brad
currently we have rally (portfolio mgt, ppm tool and delivery (scrum, kanban, etc…) and jira (for issues only) and am looking to do a comparison/case study as to whether to switch all to jira agile (aka GH) but see that jira has introduced FOLIO (aka Structure) about a year ago for portfolio mgt.

i cant seem to find anything that compares the 2, cost benefit, etc…

do you have any suggestions/advice/direction?

really appreciate your blogs

thanks
Joel

Brad April 13, 2014 at 10:47 am

Joel,
I haven’t used Folio myself, and I’m not aware of any comparisons. It appears to have useful features, but I’ve often been disappointed with tools not doing a good job with the advertised features. I would definitely want to evaluate the tool carefully before committing to switch from one to another. Rally’s people may have done some comparisons and may let you speak to someone, but of course they’d be biased. The first question I would ask is, what problems do you have with your current tool set? Is it really worth the effort to switch? Would the new tool address your specific problem but have other weaknesses?

Leave a Comment

Previous post:

Next post: