Sprint versions vs Release versions in Jira and Greenhopper [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this 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 beca开发者_如何学编程use 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?

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

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

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.

Just use rapid boards in GreenHopper, they was introduced not so long time ago, but they give almost all you need.

You can put LABELS on your issues, for instance, 'sprint-1', 'sprint-2' and so on. Then create issue FILTER. Then create RAPID BOARD based on filter. At the end you will get nice board with current issues of sprint-X regardless version and even project.

Please, check that Sprint essentially is not version of software. In real world when you have more than one customer you need to fix and support a lot of versions but you still need to keep everything on track. In this case sprints are still great but they just represent amount of job that should be done during time period. Anyway, version is what you will present to anybody outside your development time. So, do not mix versions of the software and sprints ('mapping' between time and tasks)! Do not use hierarchies where sprint version is child of real software version! Keep unrelated things separated!!!

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.

I try to use K.I.S.S. whenever possible, so I've been using the label field to mark releases. I rarely need to see the release in the context of scrum/taskboard. So when it comes time to view all items in a release, I just run a search for my release name.