Original summary: GreenHopper misuses the concepts of "epics" and "themes"
An epic is a placeholder for a collection of user stories that will eventually be defined (this has to happen before they're added to a sprint). Epics can be prioritized in the Product Backlog, along with all the other Product Backlog Items.
A theme is a coherent set of user stories – Often the resulting user stories from an epic. You can't prioritize a theme per se, because its Product Backlog Items may not necessarily be in a consecutive order.
GreenHopper is mixing the two concepts, leading to the following issues:
- You can't prioritize an epic (the issue type) in the Product Backlog. They don't even show up in the Product Backlog.
- The "epic" functionality is in some aspects confusing and cumbersome, because it mainly deals with themes, while also assuming that epic = theme. One consequence is having a redundant "Epic Status" field that users must somehow keep in sync with the "Status" field.
- You get a separate pseudo backlog for "epics", which allows you to prioritize them. This doesn't mean anything in Scrum.
Older versions of JIRA/GreenHopper used to get these two things right, albeit with an interface that wasn't as helpful as the new Rapid Boards: Themes were a type of label and epics could be prioritized.