Thursday, December 17, 2009

Jira and GreenHopper for agile project management

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.

12 comments:

emachado said...

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

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

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

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

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

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.

Bill Schneider said...

Hi Brad, I started down a similar path of using JIRA versions to represent iterations, and found that even with GreenHopper, the JIRA-generated release notes are no longer useful. Although GH gives the ability to group versions together into releases, there isn't always a clear parent-child relationship between iterations and releases.

Your original post already gave the example of a bug fix against a previous release being mixed into an iteration of stories for a subsequent release. Or, along the same lines, you might have some experimental activity that isn't going to be released with the rest of the stories in the iteration.

This makes sense for velocity tracking--all these activities take time and count against your velocity, limiting the number of other stories you can complete. But the JIRA release notes are now no longer useful - they give you a list of things in an iteration, which may be a combination of multiple releases or some things that aren't being released at all.

Ideally, there would be a way to extract the set of JIRA issue keys for release notes from SVN logs instead of by a set Fix Version/Iteration.

emachado said...

Hi Brad, I think that finally I'm able to explain myself in a better way. After my first evaluation of JIRA+GH I realize that even if this tool is great for organizing your development effort it's not the best tool for initial planning and especially for getting initial user requirements by User Stories.
So I configured a series of Confluence (Wiki) templates for creating and discussing user stories in a collaborative way. Only when we approved one of this US we move it as a formal requirement into JIRA+GH.

So, far I think this approach helps to get the best of the two worlds.

Project Management Software said...
This comment has been removed by a blog administrator.
IT Support Sherman Oaks said...
This comment has been removed by a blog administrator.
Project Management Software said...
This comment has been removed by a blog administrator.
Andy said...

What you think about JIRA's UI and overall usability? One of my friends started using JIRA when he switched jobs (he used our Scrum tool before), and after a few weeks of using it he complains that navigating projects in JIRA+Greenhopper is a nightmare: complex and unintuitive.

How do you rate it as a long-time user?