Difference between epics and Features

Asked

Viewed 7,214 times

8

In Visual Studio Team Services you can organize the backlog in epics, Features and user Stories.

For each Epic, a set of Features associated can be defined, and for each Feature a set of user Stories associated can be defined.

What I don’t understand yet is the difference between epics and Features. From what I’ve researched "Epic is a very large requirement, which needs to be divided into user Stories", but I don’t understand the difference between this and Features.

Alias, even that definition of Epic is subjective, because after all, as I know something is big enough to be a Epic?

That way, what they really are epics, what they really are Features and what the real difference is between the two?

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
software-architecture software-engineering software-project project-management requirements

  • Issue not properly marked as software project. Removing this tag will make it easier for users to find questions.

4 answers

8


I’ll explain to you how you understand the code, even if you don’t have a direct relationship between the terms:

Think about Epic like the namespace, in Feature as the class, and in story as method. Because in each development has a module that has objects that have behaviors.

Reinforcement that there is a direct relationship between them, it is likely to have a different granularity when going to put in code.

So Epic is a general description of what is desired 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. One example is managing products.

Already the Feature is something a little more concrete than it will have, has a little detail of what that is, its function. In case it is complex should also keep within a development interaction. As an example we can mention insert the engineering of the product or the sale of the product.

As Stories say what should be done, what operations the user will do on top of that Feature. Examples may be: seller issues sale order, financial approves sale, stock separates products, forwarder issues invoice.

Obviously a story can use a feature within it, just as features can have other features. 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 is not about size* but about greatness, which are different things. Epic is at a level above summarizing. It’s like a country. There are countries smaller than states and municipalities, so size doesn’t matter, but its scope does.

All of this is part of the requirements analysis. If you do wrong, and everyone does, development gets complicated.

  • I think I understand it better, the idea would be to go to each level further detailing what the system needs, and when we break an Epic in Features we are giving more details of the requirement, but still not going too deep, and the same with Stories, but then being very specific about each requirement? Anyway, is there any relation of any of these hierarchy items to use cases? It seemed to me that the use cases would be documented by Feature, but by their examples of Tories I was half in doubt.

  • @Leonardo Basically this is it, not that you need to maintain a proper hierarchy, as I said in the answer. Use case in fact is very close to Feature, but it is done a little differently. The truth is that it has to be understandable, has to meet your need as a developer or your team. It’s good not to invent too much to keep good communication with other people, even those you don’t know that will mess with the system in the future, but you don’t have to follow strict rules.

3

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 shop system:

  • Epic 1: Logistica
    • Feature 1: Stock Items
      • Story 1: As a stock responsible user, I wish to list items that are in stock;
      • Story 2: As a package receiver agent, I wish to inform you that new products have arrived in stock
    • Feature 2: Tax Notes
      • Story 1: As an accounting user, I want to launch Nfs into the system;
  • Epic 2: Online Store
    • Feature 1: Shop Window
      • Story 1: As a customer, I want to filter for products on sale
      • Story 2: As a customer, I wish to add an item to the shopping cart
    • Feature 2: Issue purchase order
      • Story 1: As a customer, I wish to create a purchase order
  • Epic 2: Finance
    • Feature 1: Audit in purchase orders

So you can break your project into size of delivery values.

You can see more on Guis of SCRUM in Brazilian Portuguese.

-1

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

-1

Browser other questions tagged software-architecture software-engineering software-project project-management requirements

You are not signed in. Login or sign up in order to post.