Sprint versions vs Release versions in Jira and Greenhopper [closed]

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

Answer 2

We have been faced with the same problem in various organisations, where a team is not only working on multiple releases (like you are detailing in your example) but also where the team is involved in helping out the support organisation when customer issues are raised or when the User Acceptance Testing of previous releases, show issues that 'need to be dealt with' immediately.

We therefore introduced a concept where issues are separated from tasks, but linked together using the 'issue linking' feature of JIRA. Issues (or specifications like we call them) are managed in a release project, while tasks are managed in a team project.

The versioning in a release project denotes releases (i.e. 2.2-patch1, 1.1 ...) The versioning in a team project denotes sprints (sprint 10-15, sprint 10-20)

The release project only contains bugs, feature requests, inquiries .. The team project only contains tasks, stories, ...

Automation allows us to keep the specifications and related tasks in sync: The typical scenario runs as follows

• A specification is created in a release project.
• A support person creates one or more tasks in the team projects, and links the specification with the tasks using a 'is implemented by' link.
• From the moment that work is started on the task, the specification advances to a 'in development' state.
• The specification is considered resolved once that all related tasks have been addressed

The transitions for the specifications are triggered automatically. This concept of separation between specification and task allow you to support many different project organisations - such as

• An epic which needs to be developed over a number of sprints.
• An issue which needs to be addressed by multiple teams in various locations
• A team which works on a new product and maintains an old.

I can provide you more information on this subject if interested.

Francis Martens