Given that we already force-rank stories in a Backlog.
And we estimate story points.
We should be able to provide a per-sprint, story point "Velocity" and have GreenHopper automatically plan sprints with tickets by walking down the backlog.

As changes are made to the backlog, these sprints should be re-planned automatically, rather than requiring manual effort to move stories in and out of sprints.

To get an idea how this should work, look at Pivotal Tracker. While their tool has a long way to go for Enterprise use, they've done a good job of making backlogs and sprints almost manage themselves. The contents of sprints will change many times to adapt to changing requirements and circumstances, as reflected in a well-maintained backlog.

With all GH's additional data and configurability, GH could automate sprint planning even better than Pivotal Tracker does, reducing the effort required to just maintaining a solid backlog.

Further, once there has been some progress down a backlog, it is possible for GreenHopper to calculate our velocity empirically, replacing our manual "default" velocity with a more justifiable, data-driven number.

I had to write a Jira plugin to provide us with Velocity, Iteration Views, and Release prediction, but I'm not asking for any of that for now. It just seems silly to have to manually drag stories around to "create" sprints.

Sprints will occur in reality, whether we construct them in GreenHopper or not. Let's make it so those sprints are both planned and tracked automatically, just by having a backlog and burning it down.