Relationship between user story, feature, and epic?

Question

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

According to this question, a feature is a collection of stories. One of the answers suggests that a feature is actually an epic. So are features and epics considered the same thing, that is basically a collection of related user stories?

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

Epic -> Features -> User stories

And that 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?

Answer 1

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?

Answer 2

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 required to implement it.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
(archived link)

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

Answer 3

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.

Answer 4

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

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.

Answer 5

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

Answer 6

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.

In the 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.

Answer 7

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.

Answer 8

Our organization has over 2,000 developers, so the answer to this question is important to fluent and clear communication between the hundreds of Agile teams we have working together on our common product. For a very small organization, you can have a very simple structure that doesn't even need to be hierarchical (as others have answered). However, for large organizations, there is definitely a need for some organized, scaled, consistent hierarchy - and therein lies the problem in striving to make a hierarchy out of something that's not strictly hierarchical.

Incidentally, we refer to each of these disparate levels as "work items". Some organizations (including some of the respondents above) refer to disparate levels as Stories or User Stories (and we have in the past too), but we found this too ambiguous, so we now refer to them generically as Work Items.

The best we have "officially" done thus far is to follow Dean Leffingwell's SAFe structure of Investment Themes and Business Epics being at the top (and second from the top) of the hierarchy, then Features under that, and finally Stories under Features. According to Agile, Tasks are always under Stories, so we are careful not to reuse that term any higher up. We chose to follow SAFe to at least have SOME consistency across all our teams.

But this is still insufficient for our needs. We define a Feature as a clearly valuable deliverable to a consumer of our software product (i.e. we list these Features on our announcements of upcoming Releases). And we define a Story as a smaller amount of scope and work that can be delivered in a single Sprint by a single Agile dev team. We are also now STARTING to follow the SAFe definition of Investment Theme and Business Epic at the Portfolio level (and not below this level). And we are STARTING to NOT use our OLD definitions of "Theme" and "Epic".

We are now slowly evolving in this direction, but the wheels of progress grind slowly. We are still struggling with how to split work into bite-sized chunks so that we can define the work and get it done smoothly by multiple teams. To do this, we see a need for a "Sub-Feature" which is smaller than a Feature but bigger than a Story. Sub-Features can be used for chunks of work done on a Feature by EACH INDIVIDUAL team, or chunks of work done by a SINGLE team at different times (in different Sprints, or even different Releases).

We also need multiple hierarchical levels between Feature and Business Epic, but we haven't solved this one yet, other than to just call them "Themes" - which we know is not the correct term, as it's easily confused with SAFe Investment Themes. For some big projects (releases) we have as many as 5-8 different hierarchical levels, each one breaking the work down into smaller and smaller chunks. You can think of these Themes as being "Feature Groups", but that's not necessarily the correct term either.

I think it's important to try to use terms that offer clarity rather than ambiguity. So anyone referring to a Story means the smallest unit of work that can be done in a single Sprint (except for the Tasks under the Story), and Sub-Feature means the smallest unit of work on a Feature that can be done by a single team. Likewise, a Feature Group is one hierarchical level above Feature. Above that it gets a little fuzzy, so we usually just call them Themes, and we allow Themes as parents and children of other Themes. We try to restrict the Feature, Sub-Feature, and Story levels to a single level each (Features should not be children of other Features) but we are not yet 100% successful in restricting this.

I know we could use "Tags" to organize some of this, but tags don't give us the organizational work breakdown structure that we need to categorize the work between all of our teams. By definition, tags are ambiguous (many-to-many relationships), but a hierarchy is strictly one-to-many.

The bottom line is that this is still a work-in-progress for us, and we're still struggling with it. But adhering to the SAFe definitions of Theme, Epic, Feature, and Story has us moving in the right direction!

Answer 9

Product Backlog Hierarchy is pretty much dependent on the product size and its modularity (number of product areas defined).

For small Projects: Epic > Story is more than enough; and you call either the "feature".
Large projects might become alike to: Novel > Theme > Epic > Feature > Story

The best example might be the following:
Novel = MS Office
Theme = MS Word / MS Excel ...
Epic = Tables / Font Directory ...
Features = Basic Table / Table Color Scheme / Operations with Cells ...
Stories (for 'Basic Tables' Feature within 'Tables' Epic) = Add Table / Draw Table / Insert Raw / Insert Column ...

What I believe is beneficial to keep in mind when defining your own scaling for backlog is:
1. Story: a) always feasible within one sprint; b) not always testable for end-users
2. Epic / Feature: a) doesn't fit one sprint duration and needs to be decomposed; b) always should be testable for end-users; c) always shippable, can be monetized - get ROI calculated for it
3. When considering add or not Epic > Feature section or stick to Epic > Story: I'd recommend to insert Feature in between Epic and Story only when: Epic doesn't fit even 1 Release, so you need to define shippable element that will fit 1 Release duration.

Hope this is helpful.

Answer 10

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.