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

Shouldnt a sprint have in theory a "shippable" product at the end? Which means a sprint has the issues either solved or "fails". That is why I'd recommend splitting the issue in smaller pieces.

Answer 2

Hi,

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

Answer 3

I too have been plagued by the same problem and have found the feature request in jira/greenhopper to add a new field for sprints to allow tracking of sprint and release version information independently.

If you want to see this become reality as much as I do, then go over to http://jira.atlassian.com/browse/GHS-945 and vote for the issue. This quote sums it up: "If GreenHopper had iterations as first-class citizens..."

At the moment though, it is likely that we will have to create a new field called versions in jira and use that to track the 'real product versions' that an issue relates to. We also have a commit hook in our source code repositories, so when a developer makes a commit, it will update the jira ticket with the 'real product version' that relates to the source code they are committing. We keep this information in a config file so the commit hook knows what version to use for what source code repository/path. This is not ideal, but it is our only option at present.