We are using GH 5.8.7, when open GreenHopper administration screens, the greenhopper labs displayed as below:
----------------------
GreenHopper Labs
GreenHopper Labs is a testing ground for experimental features that aren't quite ready for prime time.
They may change or disappear at any time. Details on what is currently being tested can be found here.
Features: Scrum for Rapid Board
Analytics - Allows GreenHopper to collect Rapid Board usage data. Enabling this helps us make the product better based on customer usage patterns.
----------------------
There isn't a option about Sprint field. Would you please provide more ifnormation about how to enable that and how to test?

I think JP means that he is looking for a demo instance.

JP: You can find that here:
https://jira.atlassian.com/secure/RapidStart.jspa

Hi JP,

You can go ahead and test it today The feature is enabled as a Lab option in GreenHopper 5.8.6 and above, just go the Labs section in the GreenHopper administration screens (or you will see an option to enable it on the Getting Started page if you are an admin).

Thanks
Shaun

Hi All,
We're pleased to note that the new Sprint field has actually been added in 5.8.6 and above with the introduction of Scrum for thr Rapid Board in labs. If you'd like to try it out and provide feedback while we continue to implement this new experience we invite you to enable the lab.
Thanks,
Shaun

.. and if you have any testable version somewhere, I would like to try it, please.

-JP

Hi,

We have following issue with Greenhopper.
1. We have timeboxed(2 weeks) sprints, like this

Unscheduled
Product Backlog
|
[-]-> Release 1 Backlog
|    |
|    |--> Sprint1
|    |
|    |--> Sprint2
|    |
|    |--> Sprint3
|    |
|    |--> Hardening Sprint4
|
[-]-> Release 2 Backlog
|    |
|    |--> Sprint1
|    |
|    |--> Sprint2
|
[+]-> Releases
...

2. Then we have those "Release Versions" where we would like to have Road Maps and Release Notes

Unscheduled
Product Backlog
|
[+]-> Release 1 Backlog
|
[+]-> Release 1 Backlog
|
[-]-> Releases
|    |
|    |--> 1.0.0.0
|    |
|    |--> 1.0.0.1
|    |
|    |--> 1.1.0.0
...

—

So, the issue is that..

1. when we plan Releases and create our Roadmap we drag&drop those issues to Releases and to Version like 1.0.0.0
   • this works fine and we can get those planned Roadmaps and early version releases from Fix Version/s field (NICE!)
2. when we start planning sprints, teams splits stories/features to sub-tasks, and they throw whole parent task to sprint
   • well.. now we lost that release and roadmap and early release notes
   • I understand, that we could throw only sub-tasks to sprint, but..
     • team wants to see parent tasks in sprint level(Planning board), because it is difficult to know which "implementation" sub-task is which
     • some of the tasks are so small, that we do not want to use time to split those to sub-tasks

So, any possibility to add

1. "Append Version" to Planning Board (e.g. CTRL button to Drag&Drop)?
2. "Append Version" to Bulk Change

Regs,
-JP

Hi Rob,

Yeah, you are kind of making the same point as i am.
Though i know it's not very 'Agile', our Product Owners do schedule a few sprints ahead. That's more or less part of the 'Capacity Management' / 'Milestone Planning' (can i get %amount% work done with %amount% of time)

@Shaun; multiple iterations would be great, but i suppose (just trying to think with you) having the ability to 'mark' multiple sprints (like you can do now with the next one) would suffice for us as well.
We would still have to 'overhaul' our current sprints and backlogs, but that's something we can cope with, i think.

Regards,

Edwin

Hi Shaun

The Rapid Board feature is great when Planning a single sprint (without using fixVersion), however I am pretty much making the same point as Edwin ( at least I think I am ). The fact that you can't use the new field to plan multiple iterations.
I haven't had much time to play with the rapid boards to be honest but I use the drag/drop functionality in the standard planning board quite a lot to schedule issues in future sprints. However it seems like I still have to use the fixVersion to do that.
Granted I can just drag every issue to a version that is an actual release and then (correct me if I am wrong) do macro planning using the rapid board, one sprint at a time. My main issues here are:

1. You cant use the sprint version on the standard Planning board
2. There is no correlation between existing sprints and the rapid board
3. I can only start one sprint and plan the next. Project management becomes extremely difficult here and there is a backwards step in the functionality as with the current planning board I can front load as many sprints as I like. the new rapid board makes the process much more reactive and puts project planning in danger as it forces the user to do last minute planning.

From your previous comment, the new sprint field is not available to the standard planning board so it will become clunky when trying to quickly get cards into a particular sprint.

Hope that is a better description of my questions.

Also as already mentioned, there is currently no easy way to move fix versions to sprint fields, and as neither are visible between rapid board and planning board, it makes each feature mutually exclusive and introduces another way to confuse how you are planning your sprints.

Hopefully I am not missing something fundamental here

Rob

Hi Edwin,

You're right that the current version only plans one sprint in advance but during a Sprint you can still use the Plan mode to rank stories and measure potential future Sprints by dragging the Sprint marker.

We're currently focusing on making this experience as slick as possible but Multiple Sprint planning will be something we tackle thereafter.

Thanks,
Shaun

Hi Rob,

I'm not sure what you mean, using the Scrum rapid board (which is in labs while we continue to enhance it and make it the best experience possible) you can plan a sprint using the new Sprint field (with no use of fixVersion).

The Scrum Rapid Boards are still missing quite a few features but we would appreciate any and all feedback while we continue to build them out. They are ready for basic Sprint planning now and we will greatly expand the capabilities over the next couple of months.

Thanks,
Shaun

@Shaun Clowes

So this particular feature still hasn't been implemented! If we want to schedule cards for sprints, then we can't do so using this field and we have to keep on destroying our Versions by using them for Sprints.

Therefore my original question still stands. When do you plan on completing the feature outlined in this Issue? And if this will not be implemented until version 6, when is version 6 on your roadmap?

Hello Shaun,

If i understand it correctly, in the new 'Scrum' we are only able to plan one iteration, release/complete it, then plan the next one. Is there an (i know you guys don't really do ETA's) expectation about when multiple iterations are supported?

Regards,

Edwin

P.S Love the new 'Scrum' functionality, with the 'Plan' and 'Report' modes.

The new Sprint field is completely unrelated to fixVersion. The field can only be used on the Rapid Board.

Thanks,
Shaun

How this field relates to Fix Version field? Can Sprint field be used on Planning Board (not Rapid Board only).

Hi All,

We're pleased to note that the new Sprint field has actually been added in 5.8.6 and above with the introduction of Scrum for thr Rapid Board in labs. If you'd like to try it out and provide feedback while we continue to implement this new experience we invite you to enable the lab.

Thanks,
Shaun

I see that even with Jira 5.0, Greenhooper version is still only 5.9

1. Does this imply that no GH 6.0 until much later version of Jira
2. How many 5.9 versions will you go through before finally giving in and implementing this feature or pushing it back (5.999.999.9) ???

What is the status of Greenhopper 6.0? When can we expect it?

Please provide a migration path for existing GreenHopper users to convert existing sprint names (currently stored in fixVersion) to use the new Sprint field.

Otherwise we'll have a discontinuity where old sprints are still based on "fixVersion" and don't show up as sprints in GreenHopper 6

This would be a huge help for us as well. Right now we are using Fix Version for sprints and basically track releases manually. It sucks.

We use Fix Versions for both Sprints and Release Versions. It's a little more to manage as it means we have to manually go through and add the Release Version to "release visible" features, but it's worked ok for now.

I vote for B. Fix Versions are specified for Projects in Jira independant of Greenhopper and thus are used for issues that are not even planned via GH. The concept of a Sprint is clearly "agile" and thus lends itself to be modeled in a separate custom field that comes with GH.

What should we do for now? (so that it would be easy migration when GH 6.0 is available)
A. Use "Fix Versions" for Sprints and have a custom field for development branch versions?
B. Use "Fix Versions" for development branch versions and have a custom field for Sprints?
C. Have labels instead of custom Fields?

Adding link to more information on Atlassian Answers in Status.

Is there an update on when we might see GH6 in production? We have recently migrated to Jira with GH and being able to use the fix version field for actual versions that might be inside or outside sprints would be great.

+1 Implementing Sprints as a first class field, independent on Fix Version, will allow us to use greenhopper across the org instead of only for a few select small projects.

I have added a moderately related issue: GHS-2796.

GHS-2796 solves a somewhat different problem; but it does allow for better control of what is displayed in the Planning Board, which would lead to better flexibility when implementing various workarounds and/or processes and mechanisms in GreenHopper.

Please have a read of the issue - and if you like it, please add your vote!

We do the same process. The same sprint can have multiple Fix Version.

This is major issue for our projects too. We need to fix several releases during the same sprint.

Added our vote for this request. We agree with the priority, it's a blocker also for us since we work in sprints mainly independent on releases; similar as others indicated. We have already teams not using Greenhopper anymore for exactly that reason. We would really appreciate if the issue gets prioritized and picked up eventually.

+1 Any update since September 27? That's a pretty big spike!

How does the Atlassian GreenHopper team use the Sprint and Product version boxes ?
If you have say some tasks in a "Beta 1" version box and some tasks in a "Beta 2" version box and you would like to solve them in a given sprint. How do you keep track of the "Beta 1" and "Beta 2" version progress ?

Please give us some ideas for workarounds etc. since this is a really big issue when using GreenHopper with Scrum.

In the context of an individual project in JIRA, we use GH to create multiple versions for product releases and also for sprints. The issue with using versions for sprints is that issues can relate to multiple versions (ie. Release A and Custom Release B), and dragging and dropping from the planning board onto a version in GH wipes out the "fix for" versions. It would be very helpful if GH allowed for a separate sprint field, or if it would maintain the version list when dragging and dropping into the sprint version.

+1

We have Projects (funding based) Components (distinct software products based) and Versions (releases for products, and currently sprints)

We need sprints separated from product versions, and the ability to plan (roadmap style) both sprints and versions.

We would also like to see sprint/iterations as orthogonal entities to projects/versions.

See also the above comment from Lewis Baker.

In our department each sprint contains multiple products/versions, for which some fixes are made or some small improvements are planned. Sometimes they are released within the same sprint other times in another up coming sprint. Also for other departments it is very confusing to see the sprint numbers appear in the 'Affects Version/s' and 'Fix Version/s' fields. Other departments use the products with version numbers, the sprint iterations do not make sence.

See discussion in forum also: http://forums.atlassian.com/thread.jspa?threadID=34728&tstart=0

Because iterations need to be represented as separate versions and a team might work on multiple milestones in an iteration we can't see a consolidated view of an iteration.

It would be great if iterations and versions could be conceptually separated to allow a view on iteration and milestone hierarchy. Currently we shoe-horn iterations into components to make this work, but we loose all the date based functionality and releasing and is a pretty big hack.

I did identify another workaround which involves adding a separate version for each iteration and adding this to each story, however this is a manual step and error prone, but seems like it could be straight forward for a programmatic approach (i.e. Greenhopper).

Forgive me if this is a dumb question, but doesn't implementing #2 require implementing #1? So the only non-overlapping design option between the 2 options (meeting #1 but not #2) is to have a new sprint field that is limited to a single project. It seems like that option should be discarded as unnecessarily limiting - 1-1 is a subset of 1-N.

Hello,

Thank you for the information you have provided, it is great to get an understanding of how GreenHopper customers plan their sprints and how they manage their un/released versions.

There are two separate issues which have been discussed above, namely:
1) add a new field for sprints to allow tracking of sprint and release version information independently
2) any one sprint may incorporate tasks from multiple projects

To minimise confusion I am going to update the summary of this issue to reflect the original request - a separate field to allow tracking sprint and release information independent of one another. Future discussion on this issue should be kept to the topic of managing sprints and versions within JIRA and GreenHopper.

The second issue has previously been raised in GHS-1800. If you are interested in the ability to have one sprint incorporate issues from two or more projects please view, vote and comment on that issue instead.

Thank You.

Regards,
Nicholas Muldoon

Dear Atlassians,

Any plan for this one ? This one is becoming quite critical for us. It is also on the top of GHS popular list for a while, but I still see no actions from your side.

I'm also wondering...you do use Scrum for your own releases don't you ? How you guys do manage your Sprints using your own tools without this feature implemented ? I'm really keen to hear about your own experience and recommendations to help us running Scrum teams over multiple releases with GreenJira (or JiraHopper if you prefer ).

Please let us know.

Yep, that sounds pretty much like what I'd like to see: the ability to have issues belong to both a Version and a Sprint, independently of each other. Burndown charts should generate based on items that are resolved/closed during the date boundaries of a Sprint, and Versions just continue to behave like they always have. If the same awesome drag and drop UI for associating Issues with Versions in Greenhopper could be used for associating Issues with Sprints, that would be the money.

+1 (and I'll point my co-workers to vote on this too)

GreenHopper's insistence that sprints are versions is our show-stopper for adopting GreenHopper. In my opinion it incorrectly models what a sprint is in Scrum; and it is broken for any company where any individual works on more than one project during a sprint. This has bugged me for several years, I'm glad to see GreenHopper join Atlassian, and am revisiting this to see if anything has been done.

A sprint is a block of time for a team to accomplish something; It is much more appropriate to bind a sprint to a Group of users than to bind it to a single project. Work is scheduled and tracked for the sprint; and in many cases this work will span multiple projects. I think of a sprint as a bucket that issues (from any project) are mapped into.

A version is a release of a project, containing a set of new features/improvements/bugs. The model of a version is Jira is solid, time-tested, and works well for us. But versions and releases have no direct association with what sprint the work was done.

We'd like to adopt GreenHopper, the planning boards and workload management tools look great, as do the the burn-down and burn-up charts. In the absence of a professional plugin that meets our needs, we use a custom "Sprint" (Select List) field (values "sprint 1", "sprint 2", ...), and we use some SQL scripts to generate burndown charts. The sprint field is global, and if we want team-scoped sprints, we insert a team name into the sprint name.

I'd really like to see the GreenHopper team implement a new custom field type, for managing Sprints. Call it a "Sprint field". Sprints should have a start and end date, and a team. It should be easy to create new sprints from existing sprints (eg, same team, next 3 consecutive weeks). And, all the task planning and management tools within GreenHopper would work for scheduling and tracking work within a sprint.

+1 vote.
Pretty much situation as Maxim and Lewis (details GHS-1772)

As workaround, for avoid Daily builds mess with Sprint, we add version-type fields call : "Fix for Build" and "Affect Build"

• they are all and always "Released" in Manage Version (to avoid them appears in Planning Board)
• We keep visible the last 5, and some special one call "Next Code build" and "Next Data Build" (for the bug fixes)
• all others are hide by archive them (the ones obsolete and the far to come)

Pro :

• more easy to list Sprint in both GH Boards and Version in Jira Scree. All builds are regroup together, not mess up with Sprint
• we keep track bugs appears/resolved in which builds during which Sprint

Con :

• It's interesting workaround that works but still a workaround.
• Have to rethink definition of "release" since all Builds have all same status "released" in Jira, even if the coming ones are not actually.

I think Lewis's suggestion makes a lot of sense. The biggest issue my team is facing at the moment is this.

• Let's assume that the team is working in Sprint 11 for a particular product
• During Sprint 11, we send a build to QA as part of a JIRA version. Let's call it v1.2. We associate the completed stories with v1.2 so we know when they entered the codebase and were sent to QA.
• v1.2 is tested, and bugs are found in it
• Sprint 11 ends before all the bugs are fixed.

Following the beginning of Sprint 12, we need to know the following.

• Which stories were released in v1.2?
• Which bugs were found in v.1.2? Were they fixed in 1.2, or are they still open?
• How many points did we attempt in Sprint 11? How many did we earn? How many were punted to the next Sprint?
• Which build version is in QA? Was it wrapped up during the sprint, or did it drag on?

For us, sprints are always fixed length, but builds are created and released on their own schedule. I need to know which builds were created during which sprints, and which stories and bug fixes went in to each build. I also need to know what we attempted to do in a sprint vs. what we actually did for charting. And of course, I need all the work/points/etc. to roll up in to the sprint. Hierarchical versioning almost works, but because GH forces you to release any sub-versions underneath a sprint in order to release the sprint itself, a lot of this useful information is lost when issues are transferred to the next sprint.

Lewis highlights the same kind of issues and some good solutions.

We would also like to see sprints as orthogonal entities to versions. We have teams that quite often work across multiple projects or project versions in the one sprint, particularly when transitioning from bug-fixing one release to new development for the next release.

The hierarchical versioning functionality in GH works well if your sprints are strict children of a particular release version. Although they do clutter up your version list that users pick from when reporting issues. Archiving the historical sprint versions hides them from the list but this makes it difficult to get access to the sprint versions to look at historical reports. Alternatively you can name the sprint versions with a particular prefix and sort them so that they appear down the bottom of the version list to keep them out of the way.

I've tried using non-hierarchical versions in the same project allowing you to set a release fix version (eg 1.0) and a sprint version (eg Sprint 10) but it seems that reassigning an issue from one sprint to another (eg from Sprint 10 to Sprint 11) using GH overwrites all previously assigned versions, losing the fact it was assigned to be fixed in release version 1.0.

Another possible solution for managing sprints that work on multiple release versions is to have two different sprint versions as children of their respective release versions that have the same start/end date. eg (1.0 -> Sprint 1.0M5, 1.1 -> Sprint 1.1M1). However doing this means your burndown data for that sprint is fragmented across a number of charts. It also makes it difficult to have a global overview of resource allocation for that sprint as the planning board can't select and display multiple versions at a time.

If GreenHopper had iterations as first-class citizens that are orthogonal to projects/versions then Jira + GreenHopper would be an almost perfect fit for our development teams.

Having done some more research: doesn't the master-slave relationship cover this feature request to an extent? You can make multiple Sprint versions the children of Version versions, thus keeping the features associated with the Sprints and the Versions in which they are ultimately released.

http://confluence.atlassian.com/display/GH/Setting+Up+a+Version+Hierarchy

We're in a similar situation.

• Features are scheduled in to Sprints, and should (but don't always) get completed in those Sprints.
• Every now and then, we'll have enough useful stuff done that we'll bundle the features in to a Release, which gets a version number and is sent to QA

What would be nice is if we could do the following, through whatever JIRA mechanisms make the most sense.

1) Use GH to plan sprints.
2) Track the Sprint that the feature was originally assigned to.
3) Track the Sprint in which the feature was completed.
4) Track the Version in which the feature was released to QA.

Or, if anybody has suggestions for an alternative best-practice for using GH in a traditional Scrum approach, we might just be using the tools in an unusual fashion.

Hi Vincent,

You are correct, this is a JIRA improvement. We've got it scheduled in the Wish List and keep an eye on these.

Regards,
Nicholas Muldoon

Shouldn't it be possible to "type" the fix version.
I can easily imagine multiple additional use cases for this need, ie having the ability to get all the "hotfixes" or the "major" releases only in a filter.

Well, maybe it's more a Jira improvement rather than just a greenhopper one

Ouch, I dont think this is doable.
GreenHopper is basing all its logic on the fixFor versions.

Sorry