Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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....".
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).
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
by process
by persona perhaps
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.
