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?

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

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.
–
Kris Van BaelMar 22 '13 at 6:38

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'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:

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

by process

View shopping cart

change item quantities

delete items

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

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.