Sprint versions vs Release versions in Jira and Greenhopper

Question

When using Greenhopper with Jira, it is clear that Greenhopper is using the "fixed in version" field in the Jira issues to represent which scrum sprint the issue is being worked on. This in itself is a bit hackish, because an issue can conceivably be worked on in multiple sprints, and because the relationship between an issue and a sprint is precisely that it has been worked on during the sprint, with the recognition that you might not complete the task within the planned time.

But okay, it might be a hack one can live with, at least if there is nothing else that tries to use the "fixed in version" field for something else.

But I am finding that there are other concerns that also build on the "fixed in version" field. Specifically, one should be able to see which issues are planned to be addressed in which release versions (real-life versions), and to use this information as a means of verification/QA.

How are other Greenhopper users combining these two uses of the "fixed in versions" field? Are you setting the sprint versions as sub-versions of the release versions? Are you using some custom field for the release versions? I am finding this to be difficult because the scrum team is working on multiple components, independently versioned. Also, there may be bugfix releases and feature development on the same component, happening on the same sprint.

To summarise, I find it unavoidable that the team will be working on "Some Product 3.4.0" (a feature release), "Some Product 3.3.1" (a bugfix release), and "Other Product 1.2" within the same sprint. It would not be possible to mark this sprint as a subversion of each of these three versions (across two different components). And making three different sprints in Greenhopper, would really dilute the value of Greenhopper.

Are other Greenhopper users in this same situation? How have you dealt with it?

Answer 1

There are two issues at play here.

First your sprint versions are actually "subversions" of your release version. This means that your stories actually get two values in the fixVersion field.

You can configure this in Greenhopper by setting up a master version.

So if you have a 3 sprint release for version 1.0, then you set your release date for 1.0 and put your stories in sprint 1, sprint 2, and sprint 3, such that

• 1.0
  • Sprint 1
  • Sprint 2
  • Sprint 3
• 1.1
  • ...

When you play STORY-1 in Sprint 1, you will find that STORY-1 will have a fixVersion of "1.0, Sprint 1"

For items that you're tracking for the release, but not in a sprint, simply set the fixVersion to 1.0.

Second (and this is just a tip), you can use seperate projects for your sprint work and for your production support work. This is helpful in large organizations