Link Greenhopper sprints to versions

[Anton N]

In our company we have recently started using Jira with Greenhopper, however it feels like the system configuration is not correct.

In Greenhopper, we do have a list of sprints and combine stories/tasks inside those. However, we do not use versions and rely on sprints only. This brings some problems: when we edit a task, its "Fix Versions" and "Affects Versions" fields show "None" and don't allow to pick a Greenhopper sprint. And you can only move a story from one sprint to another by doing drag-n-drop in the Agile board in Greenhopper.

From the other side, if we create a version in Jira, we then are able to attach a story to it, however this version would not appear in the Greenhopper Agile screen.

So, what is relation between Greenhopper sprints and Jira version management? Is it possible to have versions and link Greenhopper sprints to them, so that I can see sprints in Agile board, but also can assign a task to specific sprint from the edit screen?

And we use Greenhopper v6.1 and Jira v.5.1.4

[Timothy · Accepted solution]

There is no tie between a sprint an the version.

Some workarounds include putting a transition (and the screen) which asks user for a version. Or you can also do a bulk edit at the end of the sprint and set the version then.

[Anton N]

But doesn't it make sense to have a parent version with a set of sprints? What is the purpose of Fix Version field when we use sprints?

[Timothy]

It's definately a good idea and it has been raised with Atlassian here @ https://jira.atlassian.com/browse/GHS-6864

[Mark DeMichele]

I have to admit that I was annoyed when they stopped using versions, and instead went with this disconnected sprint model. However, after using it now for a while, I see it's merits. It really shines when your team works on multiple projects with separate release schedules.

What my team is doing is tracking our releases for each project by assigning stories to a release based version for each project. We acutally use the classic boards sometimes to manage the overall release. We assign user stories up front as a target for what we want to include in the release. The agile dashboard comes in handy to monitor the burndown of each release.

The rapid board/sprint then is a conglomerate of all the userstories across the projects that our team will work on this sprint. We've just started this process (with multiple projects) so I'm not 100% how it will work out, but it looks good in theory. However, there are some features that would really help. I'll list some of the ones here.

1. Ability to filter plan view on the fly using a JQL in the search field. Yes, I know you can make quick filters, but they soon get out of hand when you have alot.

2. Ability to automatically filter plan view by assignee. We have a large team and making quick filters for each team memember is annoying. We load our sprints per individual capacity. I know that's not truly agile, but it works for us. Also, using quick filters is not so quick when they are mutually exclusive and you need to "unclick" one before or after clicking another one.

3. One idea I had was to allow for multiple swimlane configs for work mode mode at least. So as a project admin, I can set up a rapid board with a swimlane config to assignees, or for priorites, or whatever. Yes, I know I can make multiple rapid boards. The problem is then I have to recreate any quick filters I make on each one. It would be better to have named swimlane configs with a dropdown on the rapid board.

4. My admins haven't yet updated our server to the latest and greatest Greenhopper with the Epic handling, but I tried it on the GH site and it seems very cool. I would love for them to somehow extend that idea to work off of components and assignees and even projects. I think if we eventually had that, we would have everything we need.

Anyway, that's my too cents.

[Renjith Pillai]

Good one Mark. Appreciate the time you have taken for writing this.

[Andre Brissette]

Same thing for me, in the begining I was not sure of the value of separating Version and Sprint but after using it for several Sprint and Release, I think it s how it should be.

It's especially true if you are working in Scrum. This setup support many important aspects of the process. For example, Scrum says the team deliver a set of functionality at the end of every Sprint BUT it s up to the Product Owner to decide wether or not it has to be deploy to the end user. Many reasons can support this decision (business strategy, quality, etc..). So with this setup you can track both when a feature has been delivered (to the product owner) and when it has been effectively "released" to the end user.

[Renjith Pillai]

In fact it's after a lot of feedback and discussions that sprints were disconnected from versions. The classic boards work exactly this way which was overloading the fix version field and the original purpose of that field was getting lost.