Product Backlog

Is there a dedicated "product backlog" view available in Greenhopper?

Does the a story in the product backlog have to be created in 'Unscheduled" or can it be added to a version.  What I found is that when I try to move a story from a version to a sprint, it will move it but will also stay in the version.  Where as the story when moved from unschedule to a sprint will move it completely out of the unscheduled bucket.

We have a project that is on going. Instead of creating new projects we created buckets with child Sprints. Our "unscheduled" issues as you refer as the backlog is enormous. Instead we are using the parent bucket as the  backlog.

However, how do we handle stories that don't get finished in a Sprint? I noticed that when I drag & drop the stories that weren't done into the parent bucket the data in the Sprint statistics in the Planning Board and charts change. We want to be able to go back and look at our progress of every Sprint. Should we copy any unfinished issues to the parent bucket instead? What do others do when tasks or stories don't get finish in a Sprint? I assume you drag them to the next Sprint, but this seems to change the statistics.  

how to conduct the product backlog?

I have a basic question about reporting on GreenHopper.   How can I create a JQL query that lists the items tagged in the Greenhopper backlog?   I have seen filtering for the sprint field, but apparently it is limited to only 'openSprints()' and 'closedSprints()'.   To be consistent, shouldn't there be a 'sprintBacklog()' function?    Creating a filter such as:

"project=xxxx and sprint not in closedSprints() and sprint not in openSprints()" doesn't seem to work either (the idea is everything that is not in a sprint, past or present) 

What am I missing? This seems like such a basic use case for managing a set of issues.

Thanks in advance

Thank you for the response.   That almost works. 

My filter looks like:

project=xxxx and sprint is empty status not in (closed, resolved) and issueType not in ("problem report", Sub-task) order by rank

This allows me to create an XML or xls report that is almost aligned with the GreenHopper Planning mode page display.   The filter picks up any issues that aren't in the open sprint.   In my case, I have a number of issues that are in the next sprint, that is, I have an open sprint, a next sprint, and a backlog.   So, even though GreenHopper lets me create a few sprints ahead, technically I suppose all the issues are still backlogged until that sprint is started. 

What field is GreenHopper using to manage the 'next sprint(s)' lists?   How can I either filter on those or filter them out?   The goal is to be able to create the same lists of issues that I am managing with Greenhopper.   The use case is that I need to export these to some reports, other tools (I have an XML to freemind/xmind tool I wrote for example.)  I don't want to just point people at the Greenhopper web page as that requires give them an account (and I can't make it open access.)

Shouldn't there be some automatic filters that get setup with every Greenhopper project that can be used to produce the same lists that GH manages?  Isn't this a very common use case?

Thanks again for the response.

-Fred

PS.  There is something very wrong with the Captcha system used for these posts.  On average, it takes 5 or 6 captua's to get it right, and this is with 4 people looking over my shoulder so it isn't just me ...I tried to attach screen shots of these but can't ...  As a result, most of us don't use this feedback mechanism as it is just way too time consuming ... I am now on my 6th captua try with no luck ...

7th ... 8th ...

Hi, we would also like to know how to filter future (planned sprints that are not open) and the backlog to create a spreadsheet. It is important to have that list for upper management that can not have access to JIRA because of network, equipment or licensing issues.

Thank you very much Rosie!

It looks like the backlog list applies additional filtering criteria on top of my filter.  What are those criteria?  In other words, what would keep an issue from showing up on the backlog if its does show in the underlying filter?