I have a sprint backlog with about 50 user stories that can be broken down into 7 epics. However, each epic is only partially represented in the current sprint.
For example, one of the epics is migrating content. For sprint 1, we will do 3/10 user stories. 4/10 in sprint 2 and the remaing 3/10 in sprint 3.
Questions:
No. Product and Sprint Backlogs should be organized in priority order.
To understand the difference between epics and user stories, there's no better source than Mike Cohn's blog entry on the topic. An epic is a large user story that needs to be decomposed before it is pulled into a sprint, while a theme is a collection of related user stories. What you're describing are stories that share a theme, not epic stories.
You're violating some very basic principles by having a Sprint Backlog that contains items not intended for the current sprint. The Sprint Backlog is built during Sprint Planning, and generally contains just the tasks needed to complete the user stories selected for the current sprint.
The Product Backlog is the project's long-term planning tool. The Sprint Backlog is just for the current sprint. Anything not done at the end of the current sprint is either discarded or placed back on the Product Backlog to be (re-)prioritized by the Product Owner.
The Product Backlog is always organized in priority order. What "priority" means is up to the Product Owner, and the Development Team must always peel stories off the top of the Product Backlog. (Note: The Product Owner can change the priority of items in the Product Backlog during Sprint Planning, so there's plenty of wiggle room if the team needs it.)
The Sprint Backlog belongs to the team, and should also be in priority order, although that's not a hard requirement. It's up to the team to define "priority" to suit their own needs. Some projects prioritize low-hanging fruit, while others try to get the hard stuff out of the way first.
Since each sprint should have a single over-arching Sprint Goal, it seems unlikely that a well-run Scrum would have multiple themes in a given sprint, but it is technically possible. If that's the case, then you could certainly do a stable sort by grouping your Sprint Backlog items first by theme, prioritizing each theme, and then prioritizing at the story- and task-level within each theme.
I will strongly suggest that if your Sprint Backlog is complicated enough to require comprehensive sorting, then you are probably doing something wrong at the Backlog Grooming or Sprint Planning levels. The entire process is worth discussing during your Sprint Retrospectives, at any rate, since each team's needs will vary.
Although the answer provide by @CodeGnome is technically correct, however JIRA Agile User's Guide mentions the following:
It may take several sprints to complete an epic
JIRA seems to use epics for categorizing the product backlog based on features or themes, which is why an epic may span multiple sprints. Epics are then decomposed into smaller manageable stories. Also, a team may work on stories from multiple epics during one sprint.
"epic" as defined by JIRA:
Epics provide you with an additional hierarchy of story management, providing planning guidance for groups of issues within, or across, projects. This allows ScrumMasters and Product Managers to measure important groups of issues that are all related by a common theme.
With that information in mind, answer to your question,
Is it acceptable to organize user stories by epics in a sprint backlog when the epic is not fully represented in any one sprint?
is yes (when looked from JIRA's prespective).
