Making Sprint field uneditable... congratulations! We've been eagerly waiting for such restrictions! Please keep making fields uneditable, unsearchable, introduce non-JIRA Epics and Sprints making GreenHopper even less usable, customizable and compatible with other parts of JIRA.... and pls do not forget to fire the manager who has decided this! Come on guys, you are going against everything which makes JIRA... JIRA! DO NOT GO DOWN THIS PATH!

We'll never install this pointless silly update, PLEASE TAKE PRACTICAL USAGE INTO CONSIDERATION! We always create bugs, reminders and assign them to Sprints immediately at the creation screen, or update it directly, why should we use the Board for this? To make the whole process slower??? Please ask your customers who pays (like me) and has to actually use your tool before introducing restrictions, do not make "ok, it will look better" kind of decisions!!! PRACTICE!!! Make your tool usable in PRACTICE, and as always the key here is CUSTOMIZABLE BEHAVIOUR, JIRA IS ALL ABOUT CUSTOMIZATION, and now GreenHopper tries to force us to use the agile approach of GreenHopper developers... Agility is about being agile, not being restricted by hard rules and practices, every company uses its own agile approach! We'll definitely do not buy GreenHopper anymore if you're going down this "we know better" path! Why not make everything configurable? GreenHopper is getting less and less agile...

Support for versions is a great step forward (haven't tried it yet but will do shortly). So long as there is an action available to add an issue to an Epic without the need to go to the planning board that would be ok. From our own experience and agile methods, the choices being made in the new GreenHopper do seem less progressive. The 'Classic' functionality is much more flexible and it would be really good if the new functionality could follow the same flexible approach. The addition of support for Versions though offers me some hope that in time we will some day be able to use the new GreenHopper scrum boards without having to reinvent the process that has served us well for a number of years.

(And if we could just go back to treating sub-tasks the same way as in 'Classic' mode then I think we'd be fully on board)

I agree that being able to add an issue to a sprint from JIRA is a requirement.  Having to create a bug, find it at the bottom of the backlog, then drag and drop is too much.  Is this change a temporary one enroute to somewhere else i.e. using a dropdown with names of sprints vs ???

Ok, i see, the note was quite misleading, in this case i take it back, sorry for the strong works but it was just the last drop,
as we have received a few updates introducing restrictions making our lives just harder like non-JIRA Epics without a way to import/manipulate them via REST API or issue navigator or make bulk changes (there are used heavily in enterprises when you have to deal with hundreds of tickets)... special hard-to-filter Sprint fields was just another change that broke the compatibilty with JIRA feature we bought JIRA for...

while we received "it's the intended behaviour, we know it better"-like answers for our feature requests like...

• displaying remaining estimate instead (beside) original on Planning page (original estimates is useless when you have to plan)
• displaying workload of team (per Assignee) on Planning page instead of total hours (without being able to check the workload there is no way to plan a Sprint correctly so we have to start a Sprint blindly then remove the tasks that cause overload one-by-one (painful process), using different reports to see the workload because there is no way to check it)
• displaying remaining ours instead of (or beside) number of tasks on Work page (when we use Assignee swimlanes), no way to check the workload of the team which is extremely important
• so planning is inheritely broken since
  • no workload planning
  • no team availibilty settings (like "XY has only 3 days in this Sprint")
  • no way to check remaining time of Stories
• no real way to filter to Sprints in issue navigator
  • your own solutions ("See Sprint 1 issues" link on Sprint report page) uses loooong links and Sprint filters like "issueKey in (RED-18,RED-167,RED-237,RED-10,RED-11,RED-12,RED-13,RED-14,RED-15,RED-16,RED-17,RED-19,RED-20,RED-21,RED-22,RED-165,RED-166,RED-168,RED-169,RED-170,RED-171,RED-172,RED-212,RED-213,RED-214,RED-234,RED-235,RED-236,RED-238,RED-239,RED-240,RED-241,RED-242,RED-243,RED-244,RED-245,RED-246,RED-247)"
• no way to bulk change Sprint fields

all these issues make it very hard to really like GreenHopper as project manager, it is great for team and daily standups to see stories and drag&drop them, but it ultimately fails in case of real world enterprise projects when it comes to planning and monitoring, reporting. I'd suggest to consult with Agile PMs and ask them for real world use-cases...

Thanks for the consideration of these...

Regards,
Janos

updated and all our sprints are disappeared! Only the backlog is displayed! PLS HELP!

To everyone: DO NOT UPGRADE, after upgrading all our Sprint are gone with all the reports, everything, only the Backlog remained....

additonal information... recreated the last Sprints for projects as a quick dirty fix and drag&dropped the Stories from Backlog....

now the Stories’ Sprint fields say that the Story is assigned to the sprint ID 18 (the old lost Sprint, name: Sprint 1) but the newly created Sprint 1 has id 20... however when I select the new Sprint 1 on the rapid board it shows stories with Sprint ID 18 and 20... total chaos.... pls fix!

We've just found the reason and the solution.... this new update contains a bug, duplicates the "Sprint" custom field so there will be 2 "Sprint" custom fields in your system... both are "Locked"... the solution is to set back GreenHopper to use the old field

use this SQL against your DB:

update propertynumber SET propertyvalue=[ID OF THE OLD SPRINT FIELD, CHECK CUSTOM FIELDS LIST TO FIND OUT WHICH IS THE OLD (the bigger number is the newer)] where id = (select id from propertyentry where property_key ='GreenHopper.Sprint.Default.customfield.id');

The newly created Sprint field remains there.... since it is "Locked"... thanks to this new update 

Could you tell me how to delete that duplicate Sprint field? Now both fields are listed as "SPRINT FILTERS:" on the "Work" board.... i could remove that if you did not lock it... anyway please tell me how to remove the "Locked" field from DB then!

We do not use time estimates in my group, but some of the other teams here does. What I hear about the remaining estimates etc. is exactly as you write - planning using time estimates is not as elegant as it could be. Have you searched the open issues on GH for these feature requests and voted for them? Or created a request for the ones not present?

 Let's help Atlassian create the product we want rather than just blow up and give sarcastic non-productive feedback to the GH-team.

Regards,
Kim

We are considering upgrading to take advantage of customizing the Issue Detail View but wanted to see if anyone else has had issues with the upgrade. It appears that Janos had a big problem when he upgraded and wanted to see if that is a bug within the upgrade or a just a bad experience.  Has anyone else tried upgrading and had issues and/or success?

Thanks!

It's a similar story for "Story Points" - Greenhopper is insisting on adding a duplicate field which re-appears when we delete it.  It's got no data, but our existing Story Points field has around 150,000 issues with values.

We can't use any of the estimate or reporting functionality because GH refuses to use the existing field

When will this be compatible with JIRA 6.0?  Our test system has JIRA 6.0...and I'd like to test out some of these new features.

Tom, as long as the version cannot be hierarchically nested like in the old greenhopper it is yet unusable for us. Especially the hierarchical way that was introduced by GH made release planning for us usable. Please provide this in on of the next GH releases.

Great new Version view... And the board is better and better to manage day to day Scrum... BUT: we still don't have an easy way to get Master Backlog, cross Projects Themes & Epics info, cross Projects Versioning. We need this to fill the communication gap between Stakeholders/Upper-Management and Version/Epics/Stories doen by Jira/Greenhopper Projects. We don't have a board that align Business and Delivery team to strategize together across multiple projects. It would be great to have gadgets or specific reports related to cross projects info.

As a CEO I want to see all Epics/Themes, Epics with estimation (Story points)  and Versioning to be able to retrospect on deliverables and to be able to strategize with my PO's, Teams... next Epics... we should tackle.... across all Products/Projects

Thank you - I didn't know. I tried it quickly and it looks great!.

I can definitively use it in Backlog Strategic sessions. Excellent.

We really like the Release Planning feature.  What release will it be available outside of Labs?

Thanks, Mark

The new Release Planning from the lab is interesting but it's only useful for a specific Project and Sprint and also if your Sprint is really perfect (commit, done, release at end of Sprint, release by Team by Sprint...).

I set a Master Backlog Board where I can see all open Sprint and all the backlogs. After enabling the "Release Planning - Plan your releases by assigning stories to versions." in the LAB,  I created Versions for 2 projects and moved some stories to the versions to plan the next release.

First I could not see the details of the Versions like explained in the doc: Planning a Version. I could not see Start Date, Release Date etc... Therefore I could not update them either. I check here: Creating a Version Still not?

Second, some Release doesn't occur at the end of a Sprint (even if you try to) and you may have stories accepted, ready for deployment from a previous Sprint. You can mark those with the fixVersion but they won't show in the Version in Greenhopper Plan view because the Sprint is closed.

Third, it is often that we do release for multiple Teams (so multiple Sprints) instead of a release by Team, by Sprint. So be able to create a Version that can handle tickets from multiple Sprints (and also past Sprints) would be very very usefull. 

Thank you

I saw that we locked some field like Epic Name. But if I want to set a filter with stories and epic name to quickly create a comprehensible report for upper-management, I can't because my Epic Name is not set to Global Context  I can get a filter with stories and epic links but then I have to do a all messy sheets with Excel vlookup. Would be so simple to get the hierarchy: Epic Name, Stories. 

Thank you