Thanks David about the link (GHS-945), that opened my eyes. It seems that people are not always aligning releases with with the sprints. And this was the reason why sprint and fix version were separated.

Anyway, I still would love to see the option to have hierarchy for the sprints. I think that functionality wouldn't anyhow prevent having sprints separated from the versions? Scrum board could still look and work the same as it is doing at the moment, but versions column on the left would have a tree structure having e.g. version 1.0 and sub versions 0.1 and 0.2 underneath it. And dragging issue to version 0.2 would set values 1.0 and 0.2 for the fix version attribute. Actually this is the thing we are doing at the moment, but we need to jump out of the Jira Agile view to set two versions.

"This was such a problem that the separation of sprints from versions was one of the highest voted tickets against GreenHopper ever, GHS-945."

Shaun, it would have been better to find a way to address the separation of sprints from versions as an additional configuration choice. That way you could have avoided disrupting the work practices of your customers who were quite happy with how the system worked. For example, I have three feature teams working in parallel each sprint. Previously with version hierarchies it was beautifully easy to get a picture (ie burndown chart) that encompassed all of the parallel sprints. Now I cannot find any way to do that. Perhaps you might consider having a sprint hierarchy?

The rapidboards are really great and flexible, but the new sprint mechanisms are really restrictive compared to how classic works. Is it really an option for us to continue to use classic? Given the impending Nov 2013 deadline I am having to figure out ways to make all this work for us using the new sprint and version mechanism. Not fun, and feels like a big waste of my time.

I have to say that I agree with Stefan and the others. I can't see the reason why there must be separate sprint field in issue, why can't we use fix version attribute for this, just like in classic board? I loved creating version 1.0 and then splitting it to sprints, which were sub versions. With that approach it was possible to use JIRA and JIRA Agile in parallel. For example developers prefer using Agile and for example QA prefer using JIRA. Now that's not possible, or will at least generate problems, since by using drag and drop you can't set more than one fix version per issue.

As an example, let's say that you are working with version 1.0 (=fix version) and you have sprint 5 in progress. Then you make a release for that sprint. How do you now define that some bug was found in this sprint release? You can't use affected version for that, as I was used to do.