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.

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.

The separations of versions from sprints is OK and makes sense, but the rapid board is not at all usable to retain the ability to plan versions. So only the sprint planning will be left which is not at all sufficient in many environments (many: according to the user comments in this tracking system). Did anyone succeed in contacting someone knowlegable at Atlassian to address this problem in a constructive (i.e. concrete) way? Would they split off the classic boards into another product or continue them otherwise? Unfortunately, I failed to bring anything constructive up in contact with support or sales.

As far as I read it, the Atlassian reasoning for dropping support for hierarchical versions, is to separate versions from sprints. There is still a need for creating a hierarchy for "real" versions. Right now I need to group several minor releases into one large release. I then need to be able to look at a rapid board version report for both the minor and large versions. The way the versions work today, this feels like a really unpleasant shortcoming.

Hi Shaun,
I find it very strange how you are jeoperdizing the trust of your customers by cutting down functions not offering any migration path to a similar function. The Rapid Board is very promising, but so far it has put restrictions on the usage that we have to find strategies for in order to adopt to your design decisions. We have, for example, three types of Epic Stories. We need to convert these to one. We have been using sub-tasks in a manner no longer possible and we have been using Fix Version/s hierarchies to structure a large backlog. If you want to keep your customers, I think you should consider the consequences when you close an issue like this with won't fix and announcing the removal of the fix version/s hierarchy without offering any alternative.

Regards,
Jörgen

Version hierarchies are a critical part of how we work. The ability to look at a burndown chart for any levels of the hierarchy is particularly useful. I can't see any way that this is going to be possible with the new GreenHopper.

Hi Shawn!

Is the classic planning board deprecated in the sense that it will not be part of any release after November 30, 2013?
https://confluence.atlassian.com/display/GH/The+Future+of+GreenHopper

You may be right that the classic boards are not the core of Scrum and Kanban and thus should be replaced by the rapid boards. You may also be right in your position that release management is a JIRA task (i.e. not agile greenhopper task).
But please understand that there are different ways to play scrum and one of them is a scrum within the release cycle.

If you still plan to not include the classic planning board in a release after November 30, 2013, may I suggest that Atlassian defines another product and provides the classic boards to their satisfied customers under a different name? We strongly need to do release planning efficiently before we can think of doing agile processes...

Thanks.

We use Version Hierarchy for modelling things like scrum-of-scrums (srum team and sprint hierarchies) ... how can we do that in RapidBoard?

Hi Stefan,

The classic boards are not deprecated and they are still supported from a critical bug fix perspective. Though it is true that we're not actively developing those boards.

I'm glad that the hierarchy was a highlight for you. Unfortunately for many users it was one of the most problematic parts of GreenHopper because for many teams there is no natural mapping between a sprint and a version. A team could easily work on items in a sprint that will go to different versions, for example bug fixes against a previous version or work on a 'next generation' product and the stable one. This was such a problem that the separation of sprints from versions was one of the highest voted tickets against GreenHopper ever, GHS-945.

So in terms of relating issues in a sprint with releases, I can agree that you'll usually need to do that, its just that bucketing them in to releases based on sprints doesn't work. What's worse is that in your scenario your planning is now disjoint when plans change. For example, if some items you had planned for release 1, sprint 3 don't get completed, then they are going to spill over in to release 2. There was never true certainty that those issues would be completed for release 1, you just marked them that way because of the hierarchical versions. You can certainly do this today (i.e mark the issues for release 1 if you wish), we're just not enforcing that with a version hierarchy.

I'd suggest an alternate approach, which is to plan 7 sprints ahead with the assumption that the first 3 will be in release 1, the last 4 in release 2. Then as you start each sprint use the sprint report to mark the issues as the correct release. That way the point of marking the items is the point at which reasonable certainty is achieved that those items will be in that release.

In any case, as I said we'd like to look more at release planning, but it won't be a version hierarchy.

Thanks,
Shaun

We agree that some form of release planning would be a useful addition to GreenHopper in the future and it's something we hope to address, however we definitely will not be reimplementing a version hierarchy because this sort of feature really belongs in JIRA.

Some of this can be achieved today using multiple fixVersions on issues (for example "Milestone 1" and "Release 1", "Release 2"), then a quick filter on the Rapid Board.

If you wish you can continue using the Classic boards for this functionality.

You see, this is exactly my problem: Atlassian is currently putting the Classic board to "deprecated", which means it will not be supported anymore (and harder to access via the menu) while the new board (even though in some areas has newer functionality and even better in some cases) does not yet completely replace the old functionality of the classic board.

Setting the hierarchy via Greenhopper was always a highlight for planning and really made our life easier. To us it is actually one of the unique features over Jira!

What I am also finding strange is that you have now two fields for planning: Version in Jira and Sprints in Greenhopper. To me GH and JIRA is one product. If versions are used for releases, what are sprints then? Sprints can also be released but could also seen as part of a higher abstraction of a release. Is your intent that I keep both separated from each other? Now, with the new approach I am losing my possibility to plan sprints within the releases. GH just adds upcoming sprints but those need to be related to a release, don't they?

Let's say I have hundred stories. These will be in a version called "Product Backlog". The project is planned in two releases. Release 1 is 3 sprints, Release 2 is 4 sprints. I now move the first few stories into release 1. I would do those via the classic board and then go to the new board and move the respective stories of that release into the current and upcoming sprints, right? Now, there is no connection between the sprints and the release (in terms of version). In my today's scenerio Sprint 1-3 are related as a parent to Release 1 which I am now lacking, which to me means I am losing transparency on (one of) the boards.

Don't get me wrong. I appreciate you working on a new GUI but I am telling you from my experience how we use Jira/GH in real life and the way the new board is designed currently is a step backwards in terms of planning releasing and sprints, which is my every day work, wouldn't you agree?

I find it very unfortunate that you just put that feature request to "won't fix" and resolved!
=Stefan=

We agree that some form of release planning would be a useful addition to GreenHopper in the future and it's something we hope to address, however we definitely will not be reimplementing a version hierarchy because this sort of feature really belongs in JIRA.

Some of this can be achieved today using multiple fixVersions on issues (for example "Milestone 1" and "Release 1", "Release 2"), then a quick filter on the Rapid Board.

If you wish you can continue using the Classic boards for this functionality.

Thanks,
Shaun