Difference between epics and features


In Visual Studio Team Services it is possible to organize the backlog in epics , features and user stories .

For each epic, an associated set of features can be defined, and for each feature an associated set of user stories can be defined .

What I do not understand is still the difference between epics and features . From what I've researched " epic is a very large requirement, which needs to be broken down into user stories ", but I do not understand the difference between this and features >.

Aliases, even this definition of epic is subjective, because after all, how do I know that something is big enough to be an epic ?

In this way, what really are epics , what really are features and what is the real difference between them?

Some examples I saw in a video on the internet:

  • Epic: Mobile strategy

    • Feature: Mobile favoriting
  • Epic: Continuous improvement

    • Feature: Botify the wordoo service
    • Feature: Improve performance
asked by anonymous 13.01.2017 / 21:30

3 answers


I'll explain how you understand the code, even if it does not have a direct relationship between the terms:

Think of epic as namespace , feature as a class, and story as method. Why in every development has a module that has objects that have behaviors.

So is a general description of what you want from the software. There are not many details and it is recommended to keep in just one interaction. It is a way to organize (group) many features . An example is managing products.

feature is something a bit more concrete than it will be, it has a little detail of what that is, its function. In case it is complex it must also keep within a development interaction. As an example we can mention inserting the engineering of the product or the sale of the product.

Stories tells what to do, what operations the user will do on top of that feature . Examples can be: seller issues sales order, financial approves sale, stockist separates products, dispatcher issues tax invoice.

Obviously a story can use a feature inside it, just as features may have other characteristics. Eventually a feature need not have stories. The epic is interesting in more complex systems. It's unusual but a story may not be part of a feature.

So epic has nothing to do with size * but rather with greatness, which are different things. Epic is at a level above summarization. It's like a country. There are smaller countries than states and municipalities, so size does not matter, but the scope of it does.

This is all part of the requirements analysis. If it does wrong, and everyone else does, development gets complicated.

22.05.2017 / 20:22

Epic, Features and User Stories are SCRUM artifacts, not VSTS definitions.

These artifacts help you break the values of your deliveries into blocks of expectations.

In a very simple example, a simple store system:

  • Epic 1: Logistics
    • Feature 1: Inventory Items
      • Story 1: As user resposable by stock, I want to list items that are in stock;
      • Story 2: As a package reception agent, I wish to be able to inform you that new products arrived in stock
    • Feature 2: Invoices
      • Story 1: As an accounting user, I want to post NFs on the system;
  • Epic 2: Online Shop
    • Feature 1: Display
      • Story 1: As a customer, I'd like to filter for products on promotion
      • Story 2: As a customer, I want to add an item to the shopping cart
    • Feature 2: Issue Purchase Order
      • Story 1: As a customer, I want to create a purchase order
  • Epic 2: Finances
    • Feature 1: Purchase Order Audit

So you can break your project by the size of delivery values.

You can see more on SCRUM Guidance in Brazilian Portuguese

16.01.2017 / 11:46

It depends a lot on some of your own concepts. Overall, Epic is something more abstract, it is a global concept and without much definition of its software. Since the feature is something more concrete and specific, I see a feature as a service that meets the needs of the user.

22.05.2017 / 20:41