The way we work with Epics, Stories and Features is as follows
Early in the project cycle, we come up with Epics. These are very high-level, almost marketing-centric, bullet-points of functionality. The sort of thing that you can use in an executive summary, such as,
Our new web site will allow customers to browse products, view availability and pricing, place orders and see their past order history
This leads to Epics such as
- Browse Product Catalog
- View Availability
- View Pricing
- Place Order
- View Order History
These are written up as user stories (e.g. As a customer, I want to browse the product catalog, so that I can make an informed purchase decision), but serve only as a starter for ten for what will be actually developed and released.
These Epics are then further broken down into User Stories. These are actual end-to-end user journeys, very limited in scope and defined in a way that can be estimated and planned independently, and developed, tested, and released in one release cycle.
The User Story is the unit of delivery. It is the user story that is complete or not complete, goes live or does not go live.
An Epic may result in a large number of user stories, not all will be developed or released at the same time.
As an example, the Browse Product Catalog epic may break down into
- Navigate Category Hierarchy
- Search by Keyword
- Filter by Product Attributes (e.g. price range, brand, colour, size, etc.)
Again, each of these would be written up in the format, e.g. As a customer, I want to navigate the category hierarchy, so that I can browse products and drill down to the product most suitable for my needs.
Generally, for most of our projects, we have tens of Epics and hundreds of stories.
Now, as we go through the story life cycle, we tag these stories with Features. For example, all the browse and search and stock and pricing stories will be tagged with, say, 'product-catalog'. Place Order stories to do with paying by Credit Card may be tagged with a 'credit-card' label and those to do with paying by PayPal will be tagged with a 'paypal' label.
These labels serve to group together stories that belong together, not because they are different types of performing the same activity (e.g. all the place order stories) but because they ought to be released together.
For example, the "placing an order paying by credit card" story belongs under the same epic as the "placing an order paying by PayPal" story, but they need not be released together.
Whereas, the "placing an order paying by credit card" story, the "processing a return refunding onto a credit card" story, and the "allowing customers to manage their saved credit cards on their account" story do seem to belong to one another. They would all have been tagged with the 'credit-card' feature label. i.e. they would all belong to the "Credit Card" feature. It is not very helpful releasing the ability to place an order paying by Credit Card, if it is not possible to process a return refunding on to PayPal, or if it is not possible to manage your saved Credit Cards on your account
Note: As a general rule, that is. This is, in the end, a business decision. If time-to-market is important, there may be a legitimate reason to go live with one of these and not the other.
Thus Epics serve to break down into (related, but separate) stories that can be developed independently, while Features serve to group together stories that should be released together.
You could say that Epics decompose into User Stories, and User Stories get composed into Features. The stories that belong to a feature are usually across Epics. Thus Epics and Features are orthogonal, not in a strict hierarchy.
In our way of working, once the Epics have been broken down into stories, they lose their purpose. We do not estimate, or plan Epics. We do not track progress on Epics. We do not release Epics. We estimate, plan, and track User Stories. And we release Features.