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.


  • Is this the proper use of an Epic?
  • Is it acceptable to organize user stories by epics in a sprint backlog when the epic is not fully represented in any one sprint?

2 Answers 2



No. Product and Sprint Backlogs should be organized in priority order.

Themes, Not Epics

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.

Sprint Backlogs Are Ephemeral

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.

Prioritization Order

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.

  • 1
    This is a good distinction between epic and theme and how they're used. It looks like we will have user stories from multiple themes (not epics) in our next sprint. This is a concession to the current project reality as opposed to a disagreement with the philosophy. I think it’s OK to break the rules as long as you know that you’re breaking them and why you’re breaking them.
    – RWL01
    Commented Aug 19, 2013 at 19:28

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.