When working on a backlog, you define epics and break them down into user stories. Epics are estimated and kept on the backlog as epics until they become important enough to be planned into one of the next sprints.

But once an epic is split into sprintable units, what do you do with the original epic? Do you keep it with the stories until all are done? Do you retire them into some kind of epic archive? Do you just delete them?

They seem like unnecessary balast once the splitting is done.

5 Answers 5


This depends on your tooling somewhat. From a process standpoint, once the Epic has been broken down into Sprint-Sized stories that can be estimated, the original Epic (which had really been functioning as a placeholder in your backlog) can be discarded. If you are using index cards, tear that Epic up!

Ideally, the resulting User Stories should be independent of one another, so their Epic ancestry would not be important. But if you want to maintain a connection to the original Epic, many tools provide a way to link it. This can also be done in the User Story itself: "[Epic] As a System Admin, I need....".

  • 2
    Keeping track of the original epic, can help team members to better understand the story and its context. Also, some hierarchy in stories can help to report state and progress to less involved stakeholders. But usually some story-categories are good enough for that. An epic could become a category of its own. Mar 22, 2013 at 6:38

If the epic was put in with acceptance criteria associated with its user story, then you test that. If it's acceptable, you close the epic. If it's not, you schedule work to close out the user story.

Ideally, all the child user stories should have implemented all the requirements of the epic.

In any event, acceptance criteria should be assigned (if they are not there already), the work to test them scheduled and the epic closed (if the tests pass).

  • Writing detailed acceptance criteria on epics seems not very efficient. Mar 22, 2013 at 6:30
  • Then there is no point in writing them, and you should start with more detailed, unconnected user stories.
    – Peter K.
    Mar 22, 2013 at 11:43

In my opinion, epics need to be maintained for communication at portfolio levels with C-level individuals in order to minimize confusion with what is in the team backlog.

There should be a backlog that is being used to communicate at that level which feeds down to the team. That portfolio level needs to know where these epics are in terms of progress (To Do, In Progress, Complete).

For small projects, probably okay to get rid of the epics and just work with the one team backlog. As this scales up, however, you'll probably need to separate the team backlog from that portfolio-level backlog and track the epics separately.

  • I think this is more specific to SAFe Sep 23, 2021 at 19:40
  • Given my answer was in 2013 and SAFe had not come to my attention until 2015 or later, I will propose that this is not specific to SAFe, but perhaps the problems I was facing at the time aligned well with how SAFe was also attempting to solve the same problems.
    – Jay S
    Sep 24, 2021 at 10:26
  • certainly. Even if you're not doing SAFe (I'm not going to lie; I am personally not a fan of it in practice, but I see its value), the framework is impressively eloquent in how addresses just about every scenario you're like going to run into. I'd recommend that team in an org of any size at least use it as a reference point. Sep 29, 2021 at 18:25

I've struggled with this and have come to understand that it really depends on how you decompose. Let's say you have some epic like ' I want to modify what's in my shopping cart'. This can be decomposed in several fashions:

  1. by method

    • I want to modify my cart detail by going to the cart detail page
    • I want to modify cart detail by a pop-up quick look modal
  2. by process

    • View shopping cart
    • change item quantities
    • delete items
  3. by persona perhaps

    • As a shopper, I want to change what's in my cart
    • As a CSR, I want to access a shoppers cart and change the items in it

In this example, if you use decomp method 1 then probably safe to drop the epic since these children are truly independent. But in 2 or 3, the children are still independent but to accomplish the goal of the original story then the children must all be satisfied. And how you estimate also depends on looking at the set (in method 3, the first story will get some points for loading the cart view that impacts the estimate for the CSR accessing the cart view).

Like justinpeck mentions above, tooling becomes very important (are the relationship links easy to set and view?).

  • This is logical. What it comes down to I think, is how your organization is setup. For example, in SAFe, #3 might be at the ART level (product managers requiring general feature sets from the business perspective), #1 might be a theme/intiative. #2 would actually be better as a story. The epic would likely be larger than this ability to modify a shopping cart but could also simply be "Update cart options" at the ART level would contain modify on detail page, modify in modal, and others". Everything else would be stories in that epic Sep 23, 2021 at 19:48

The epics are a tool to help you do your job. Once they stop being useful you can throw them away. Therefore, the answer to the question is "are the epics still useful to you?". I don't think we have enough information to answer that for you.

Don't get too about what you are supposed to do or not do. If you want to keep the epics around, do so. If they aren't useful to you, throw them away. If you don't know if they are useful or not, keep them for an entire release cycle and then decide what to do in a final retrospective.

Your Answer

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

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