How to resolve differences in use of version in JIRA and Greenhopper

[James Woods]

I am involved in the process of converting an existing project to use agile, and am wanting to use Greenhopper for planning. The project already uses JIRA for tracking features, enhancements and bugs.

I am trying to resolve the different uses of VERSION in greenhopper to the traditional use in JIRA. For example for the current release we have three branches targetting three different releases:

• 1.8.x (production support) Is currently in production and we deploy any high priority bug fixes to this
• 1.9.0 (trunk) Is the current development release and the next to go into production
• 1.10.0 (feature branch) A new feature that is not wanted in production until after 1.9 is released, but the business want to start testing and evolving it now.

We use the VERSION in JIRA to track what releases we have, and which releases a feature/bug is in or planned for.

Now we want to start organising our planning into sprints/timeboxes, and Greenhopper uses the VERSION to track each sprint. It is possible that in any sprint the team could end up doing work for all three releases.

In my last project we faced the same issue and ended up resolving it by having separating traditional JIRA tickets from Greenhopper stories in seperate projects. But this meant that every Greenhopper story had to be linked back to the original JIRA ticket that it was related to. This also required that the developers maintain the workflow and comments on two linked issues, and then me manually going through them all at the end of a sprint to audit and synchronise everything. This was a major pain point that we never resolved.

On this project I am investigating using a single project and using the features/bugs directly and not using epics/stories. I see two options here.

1. Use the VERSION for both releases and sprints. But this will produce an unmanageable mess and the planning board will become cluttered with release VERSIONS that have nothing to do with agile planning.
2. Use a custom field for the release versions. But this will then lose the power for the JIRA release management and cause confusion with the existing "affected version" and "fix version" fields.

Am I missing something obvious here, or is there a recommended best practice for resolving this issue?

[sclowes · Accepted solution]

Hi James,

You might like to try the Rapid Board. It uses a separate 'Sprint' field so that issues can participate in Sprints independently of the versions.

Thanks,
Shaun

[James Woods]

Thanks Shaun, that looks like it would do the job. Shame that my company is on an older version of Greenhopper that pre-dates the RapidBoard. But I am sure that will get upgraded in due coarse, and then I can start playing with it.

In the meantime our tactical hack is to use the JIRA version for the sprint planning and then create our production release numbers as tasks with links to the issues that are included in the release. I think that this will work ok for us, but it looks that when we get the Rapid Board this will make thinks a lot easier for us.

Thanks

James