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.

As someone whose still new to agile, I'm not sure I completely understand the relationship or difference between a user story, feature, and epic.

According to this question, a feature is a collection of stories. One of the answers suggest that a feature is actually an epic.

So are features and epics considered the same thing, which is basically a collection of related user stories?

Our project manager insists that there's a hierarchical structure:

Epic -> Features -> User stories

... basically all user stories must fall within this structure. Therefore all user stories must fall under an umbrella feature and all features must fall under an epic.

To me, that sounds awkward. Can someone please clarify how user stories, features, and epics are related? Or is there an article that clearly outlines the differences?

share|improve this question
3  
The only real answer to this is "there is no definitive answer". Every individuals/companies interpretation is slightly different. To me, features and user stories are the same, other people may make a distinction (which to me seems silly), but neither is right or wrong. I don't think anyone on earth can definitively tell you, "this is an epic, this is a story, this is a feature"... although many will try! –  MattDavey Jan 10 '13 at 10:06
    
I disagree. A feature is NOT a user story, while an epic is a user story. An example of what a feature looks like is "payment via paypal". While an example user story is, as a customer on an iPhone, I want to buy a hammer and pay with my paypal account so that I don't have to enter my credit card information. Further more, I would consider that story an Epic because it'll take more than a day to implement it. –  Joey Guerra Nov 13 '13 at 20:47
    
@JoeyGuerra The way we use those terms, you just wrote 1 user story that will result in 1 feature. We don't use "epic" at all, but our overarching word is "project" - which, to extend your example, would involve a shopping basket and all forms of payment (and possibly more interrelated pieces). –  Izkata Nov 13 '13 at 22:10
add comment

7 Answers

They are very generic term actually. There is many way to interpret them, varying in the literature and how people see them. Take everything I say with a huge grain of salt.

Usually, an Epic comprise a very global and not very well defined functionality in your software. It is very broad. It will usually be broken down into smaller user story or feature when you try to make sense of it and making them fit in an agile iteration. Example :

Epic
- Allow the customer to manage its own account via the Web

Feature and User Story are more specific functionality, that you can easily test with acceptance tests. It is often recommended that they be granular enough to fit in a single iteration.

Features usually tend to describe what your software do :

Feature
- Editing the customer information via the web portal

User stories tend to express what the user want to do :

User story
As bank clerk,
I want to be able to modify the customer information
so that I can keep it up to date.

I don't think there is really a hierarchy between the two, but you can have one if you want or if it fit how you work. A user story can be a specific justification for a feature, or a specific way to do it. Or it can be the other way around. A feature can be a way to realize a user story. Or they can denote the same thing. You can use both : User stories to define what bring business value and feature to describe constraint of the software.

User story: as a customer, I want to pay with the most popular credits cards
Feature support the GOV-TAX-02 XML API of the government.

There is also the question of scenario, which are usually a way a Feature/User story will be executed. They usually map cleanly to a specific acceptance test. For example

Scenario : Withdrawing money
Given I have 2000$ in my bank account
When I withdraw 100$
Then I receive 100$ in cash
And my balance is 1900$

That is how we define those terms where I work. Those definitions are far from a mathematical definition or a standardized term. Its like the difference between a right wing politician or a left wing politician. It depend where you live. In Canada, what is considered right wing may be considered left-wing in the United State. It's very variable.

Seriously, I wouldn't worry too much about it. The important is that everyone on the team agree on a definition so you can understand each other. Some method like scrum tend to define them more formally, but pick what work for you and leave the rest. After all, isn't agile about Individuals and interactions over processes and tools and Working software over comprehensive documentation?

share|improve this answer
    
+1 for "The important is that everyone on the team agree on a definition" –  MattDavey Jan 10 '13 at 10:08
add comment

Epic: A very large user story that is eventually broken down into smaller stories.

User story: A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

Feature: A distinguishing characteristic or capability of a software application or library (e.g., performance, portability, or functionality).

http://en.wikipedia.org/wiki/Software_feature

share|improve this answer
add comment

I caution you against applying too rigid a hierarchy to these terms. We tried to do that in my previous job. Twice. Both attempts were different and both times we found we had unnecessarily limited ourselves. The only constant was the definition of a User Story. From a planning perspective, a story is the basic building block of a project. The larger terms (epic, feature, etc.) are effectively just tags. Tags are an easy way to allow a story to exist as part of multiple Epics and multiple Features at the same time. It's not worth the mental effort to be more strict than that.

Tags work for Stack Exchange and they can work for you too.

share|improve this answer
add comment

It's just problem decomposition. They are just stories, except with different sizes.

I personally prefer not to label their sizes, but if you do that is fine as well. Ask you PM what the definition is in your workspace.

share|improve this answer
add comment

I agree like many responses that there are really no right answers since these are just terms which can be varied depending on which Agile camp you are based on and you can definitely make up your own camp as long as everyone in your team including the external stakeholders understand what they mean. It is just a way of organizing your requirement.

The answer I like is from Mike Cohn's camp and it is fairly simple.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

  • Epic is just a big Story (hierarchical)
  • Theme is just a group of Stories (pretty much like tag)

He actually avoids the term "Feature". I assume that it is mainly because it was a common term in the traditional waterfall world. Many Agile camp tends to use different terms to emphasize the differences.

So in your PM's definition, Feature is somewhere in the middle of the Epic-Story hierarchy.

Here is my info-graphic of this definition from my InfoQ article http://www.infoq.com/articles/visualize-big-picture-agile ;-)

enter image description here

share|improve this answer
add comment

I disagree with most of the answers. So here's mine.

Features and Epics are not the same thing.

  • A Feature is not a User Story.
  • An Epic is a User Story.
  • A User Story may be an Epic.
  • A User Story can contain many Features.
  • A Feature can fulfill 1 to many User Stories.

At the beginning planning phases, the discussions result in User Stories which are typicaly identified as Epics because the effort to implement solutions for them is too big to accomplish in a few days. Product Features are identified during this phase. But that's just a by-product of the discussion. Features are then used to plan a product road map, which is a separate discussion.

The Epics are taken and discussed further, resulting in User Stories for each Epic. The Features and Epics are used to drive discussions in Backlog Refinement and Sprint Planning sessions. At which time, the User Stories coming out of those discussions are refined, prioritized, and, in Sprint Planning, accepted into sprints for implementation.

share|improve this answer
add comment

In our organisation we have the following:

Theme = Used to group together a collection of stories

Epic = Describes a large user story (in truth a requirement) that needs to be broken down into user stories

Features = Does what it says on the tin, describes a feature of the product required

User story = This is the lowest level of detail from which tasks are derived.

share|improve this answer
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.