Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Mar 21 '13 at 23:59

This question came from our site for professional and enthusiast programmers.

add comment

5 Answers

up vote 2 down vote accepted

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

share|improve this answer
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. –  Kris Van Bael Mar 22 '13 at 6:38
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
Writing detailed acceptance criteria on epics seems not very efficient. –  Kris Van Bael Mar 22 '13 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 '13 at 11:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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