4 added 1 characters in body
source | link

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 itfit 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?

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 it 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?

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?

3 deleted 1 characters in body
source | link

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 it 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. ItsIt is often recommended to make granular enough that they be granular enough to fit in a single iteration.

FeatureFeatures usually tend to describe what your software do :

Feature
- Editing the customer information via the web portal

User storystories 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$

So thatThat 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?

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 it 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. Its is often recommended to make granular enough that they fit in a single iteration.

Feature usually tend to describe what your software do

Feature
- Editing the customer information via the web portal

User story 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$

So that how we define those terms where I work. Those 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?

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 it 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?

2 added 10 characters in body
source | link

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. TheyIt will usually be broken down into smaller user story or feature when you try to make sense of themit and making them fitit 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. Its is often recommended to make granular enough that they fit in a single iteration.

Feature usually tend to describe what your software do

Feature
- Editing the customer information via the web portal

User story 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$

So that how we see themdefine those terms where I work. Those 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?

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. They will usually be broken down into smaller user story or feature when you try to make sense of them and making them fit in an agile iteration.

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.

Feature usually tend to describe what your software do

Feature
- Editing the customer information via the web portal

User story 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$

So that how we see them where I work. Those 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?

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 it 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. Its is often recommended to make granular enough that they fit in a single iteration.

Feature usually tend to describe what your software do

Feature
- Editing the customer information via the web portal

User story 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$

So that how we define those terms where I work. Those 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?

1
source | link